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Abstract 


This manual describes the installation and execution of FUN3D version 12.6, 
including optional dependent packages. FUN3D is a suite of computational 
fluid dynamics simulation and design tools that uses mixed-element unstruc- 
tured grids in a large number of formats, including structured multiblock 
and overset grid systems. A discretely-exact adjoint solver enables efficient 
gradient-based design and grid adaptation to reduce estimated discretization 
error. FUN3D is available with and without a reacting, real-gas capability. 
This generic gas option is available only for those persons that qualify for its 
beta release status. 
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About this Document 


This manual is intended to guide an application engineer through conhgura- 
tion, compiling, installing, and executing the Fun3D simulation package. The 
focus is on the most commonly exercised capabilities. Therefore, some of the 
immature or rarely exercised capabilities are intentionally omitted in the in- 
terest of clarity. An accompanying document that provides example cases is 
under development. 

Release of the generic gas capability is restricted because of International 
Traffic in Arms Regulations (ITAR), so Fun3D usually distributed with the 
generic gas capability disabled. See section 1.4 for details. This manual de- 
scribes Fun3D with and without the generic gas capability, denoted eqn_type= 
'generic' . Features that are specihc to an eqn.type are explicitly indicated. 

This document is updated and released with each subsequent version of 
Fun3D. In fact, a significant portion is automatically extracted from the 
Fun3D source code. If you have difficulties, find any errors, or have any 
suggestions for improvement please contact the authors at 

Fun3D-Support@lists.nasa.gov 

We would like to hear from you. 
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Quick Start 

This section takes you from source code tarball to a rudimentary flow so- 
lution using single processor execution on a typical Unix-style environment 
(e.g. Linux, Mac® OS) with a Fortran compiler and the GNU Make utility. 
Fun3D is most commonly executed in parallel, but the intent here is to pro- 
vide the most basic installation, setup, and execution of the Fun3D flow solver 
without the complexity of any third-party libraries or packages. 

See section 1.4 for instructions on obtaining the Fun3D source code tarball. 
Once you have it, unpack the source code tarball, conhgure it for your system 
(section A), compile it, and add the executables directory to your search path. 
For C Shell, e.g., 

tar zxf fun3d-12.6-*.tar.gz 
cd fun3d-12.6-* 
mkdir _seq 
cd _seq 

../configure — pref ix=${PWD} 
make install 

setenv PATH ${PWD}/bin: $-[PATH} 

cd . . 

For Bourne Shell, the setenv command is export PATH=${PWD}/bin : ${PATH}. 
The change to the PATH environment variable can be made permanently by 
adding the setenv or export command to your shell start up hie. Next, move 
to the doc/quick_start directory, 

cd doc/quick_start 

where you will hnd a very coarse 3D wing grid (inv_wing.fgrid) intended for 
inviscid how simulation (section 4). Also in this directory are the associated 
boundary conditions hie inv_wing.mapbc (section 3) and a Fun 3D input hie 
funSd.nml in Fortran namelist format (section B.4). 

Execute the how solver (section 5.1) by running the command 

nodet 

This should produce screen output similar to 

1 FUN3D 12.6-73467 Flow started 03/08/2015 at 10:00:09 with 1 processes 

2 Contents of fun3d.nml file below 

3 feproject 

4 pro ject_rootname = 'inv_wing' 

5 / 

6 &raw_grid 

7 grid_format = 'fast' 

8 data_format = 'ascii' 

9 / 

10 &governing_equations 

11 viscous_terms = 'inviscid' 


11 


12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 

31 

32 

33 

34 

35 

36 

37 

38 

39 

40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

50 

51 


171 

172 

173 

174 

175 

176 

177 

178 

179 

180 
181 
182 


/ 

&ref erence_physical_properties 
mach_rmmber = 0.7 
cLQgle_of _attack = 2.0 

/ 

&code_run_ control 

restart_read = 'off 

steps = 150 

stopping_tolercLnce = l.Oe-12 

/ 

feglobal 

boundary_animation_freq = -1 

/ 

&boundary_output_variables 
number_of .boundaries = -1 
boundary.list = '2,7-8' 

/ 

Contents of funSd.nml file above 

... opening inv.wing.fgrid 

... nnodesg: 6309 ntet: 35880 ntface: 1392 


cell 

statistics : 

type. 

min volume , 

max volume , 

max face angle 

cell 

statistics : 

tet , 

0.38305628E-05, 

0.14174467E+02, 

143.526944837 

cell 

statistics : 

all. 

0.38305628E-05, 

0.14174467E+02, 

143.526944837 


... Constructing partition node sets for level-0... 35880 T 

. . . Edge Partitioning .... 

. . . Boundary partitioning. . . . 

... Euler numbers Grid:l Boundary: 2 Interior: 2 
... Reordering for cache efficiency.... 

... Write global grid information to inv_wing.grid_info 
... Time after preprocess TIME/MemCMB) : 0.71 98.36 98.36 

NOTE: kappa_umuscl set by grid: .00 


Grid read complete 

y-symmetry metrics modified/examined: 1102/1102 


Iter density_RMS density_MAX 

1 0.611767950151108E-04 0.68431E-03 

Lift 0 . 766897492276677E-01 

2 0 . 338742964194621E-04 0 . 1 1225E-02 


X-location Y-location Z-location 
0 . 25001E-01 0 . 43479E-01 0 . OOOOOE+00 

Drag 0 . 3521 17350083380E-01 
0 . 41388E+01 0 . 24706E+01 -0 . 21321E+01 


61 0.195408502162482E-12 0.77542E-11 0.21669E+01 O.OOOOOE+00 0.65000E+01 

Lift 0 . 809619820187427E-01 Drag 0 . 108249842008451E-01 

Writing inv_wing.flow (version 11.8) lmpi_io 2 
inserting current history iterations 61 
Time for write: .0 s 


Writing boundary output: inv_wing_tec_boundary.dat 
Time step: 61, ntt: 61, Prior iterations: 0 
Done . 


If Fun 3D completed successfully, a Mach 0.7 inviscid flow over a very 
coarse representation of an ONERA M6 semi-span wing [1] at two degrees 
angle of attack is available. If not, please refer to Troubleshooting on page 310. 

With visualization software capable of reading Tecplot™ hies, you can visu- 
alize various surface quantities with inv_wing_tec_boundary.dat as shown by 
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Figure 1: Mach 0.7 flow about a coarse ONERA M6 semi-span wing at 2 
degrees angle of attack. 


the pressure contours in Fig. 1. Iterative convergence history can be plotted 
from inv_wing_hist.dat as shown in Fig. 2. Histories of all five conservation 
equation residual norms are denoted R_l-R_5, and the lift coefficient conver- 
gence history is denoted C_L. 
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Figure 2: Iterative convergence history for coarse ONERA M6 wing. 
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1 Introduction 


Fun 3D began as a research code in the late 1980s. [2] The code was created 
to develop new algorithms for unstructured-grid fluid dynamic simulations 
of incompressible and compressible transonic flows. The project has since 
grown into a suite of codes that cover not only flow analysis, but adjoint-based 
error estimation, mesh adaptation, and design optimization of fluid dynamic 
problems extending into the hypersonic regime. [3] 

Fun3D is currently used as a production flow analysis and design tool to 
support NASA programs. Continued research efforts have also benehted by the 
improvements to stability, ease of use, portability, and performance that this 
shift to simultaneous support of development and production environments has 
required. These benehts also include the rapid evaluation of new techniques 
on realistic simulations and a rapid maturation of experimental techniques to 
production-level capabilities. 


1.1 Primary Capabilities and Features 

The primary capabilities of Fun 3D are: 

• Parallel domain decomposition with Message Passing Interface (MPI) 
communication for distributed computing 

• Two-dimensional (2D) and Three-dimensional (3D) node-based, hnite- 
volume discretization 

• Thermodynamic models: perfect gas (compressible and incompressible) 
and thermochemical equilibrium, and non-equilibrium^ 

• Time- accurate options from hrst- to fourth-order with temporal error 
controllers 

• Upwind flux functions: flux difference splitting, flux vector splitting, 
artihcially upstream flux vector splitting, Harten-Lax-van Leer contact, 
low dissipation flux splitting scheme, and others 

• Turbulence models: Spalart-Allmaras, Menter k-omega SST, Wilcox k- 
omega, detached eddy simulation, and others, including specihed or pre- 
dicted transition 

• Implicit time stepping where the linear system is solved using either 
point-implicit, line-implicit, or Newton-Krylov (multigrid is also under 
active development) 


^The multi-species, thermochemical non-equilibrium capability requires the high-energy 
physics library, which is only made available upon specific request and under certain condi- 
tions, see section 1.4 for details. 
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• Boundary conditions for internal flows and propulsion simulation includ- 
ing inlets, nozzles, and system performance 

• Grid motion; time- varying translation, rotation, and deformation includ- 
ing overset meshes and six degrees of freedom trajectory computations 

• Adjoint- and feature-based grid adaptation 

• Gradient based sensitivity analysis and design optimization via hand- 
coded discrete adjoint for reverse mode differentiation and automated 
complex variables for forward mode differentiation 

Before exploring more advanced applications (e.g., grid adaptation, moving 
grids, overset grids, design optimization), the user should become familiar with 
FunSD’s basic flow solving capabilities and have appropriate computational 
capability available as indicated in the next section. 


1.2 Requirements 

The Fun 3D development team’s typical computing platform is Linux clusters; 
so this is the most thoroughly tested environment for the software. A number 
of users also run on other UNIX-like environments including Mac OS X™; these 
platforms are supported as well. Users have also run on other architectures 
such as Microsoft Windows™-based PG’s; however, the team cannot provide 
explicit support for these environments. 

The user will need GNU Make and a Fortran compiler that supports at 
least the Fortran 95 standard. During conhguration, the Fortran compiler is 
tested, and any newer Fortran features or extensions are detected are used 
to the greatest extent possible. A large number of compilers are tested by 
an automated build framework, including Intel®, Portland Group®, NAG®, 
Lahey/Fujitsu®, Gray®, Absoft®, IBM®, GFortran, and G95. 

While the code can be compiled to run on only a single processor, as demon- 
strated in the Quick Start section, most applications will require compiling 
against an MPI implementation and the ParMETIS domain decomposition 
library to allow parallel execution. 

The flow solver uses approximately 2.4 kilobytes of memory per grid point 
for a perfect gas PANS simulation with a loosely-coupled turbulence model. 
For example, a grid with one million mesh points would require approximately 
2.4 gigabytes of memory. Memory usage will increase slightly with the in- 
crease in the number of processors because of the increasing boundary data 
exchanged. Different solution algorithms and co-visualization options will also 
require additional memory. Typically, one GPU core per 50,000 grid points is 
suggested, where a 3D mesh of 20 million grid points would require 400 cores. 
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1.3 Grid Generation 


Fun3D has no grid generation capability. For internal development at NASA, 
the most common sources of 3D grids are VGRID (ViGYAN, Inc. and NASA 
Langley), SolidMesh/AFLR3 (Mississippi State), Pointwise (Pointwise, Inc.), 
and GridEx (NASA Langley). 

For 2D grids, the development team normally uses the AFLR2 software 
written by Prof. Marcum et ah at Mississippi State University Center for 
Advanced Vehicular Systems (CAVS) SimCenter. Scripts are available to fa- 
cilitate the use of this grid generator, but the generator itself must be obtained 
from Prof. Marcum. BAMG [4] is also used for 2D grid generation and adap- 
tation. 


1.4 Obtaining Fun3D 

Fun3D is export restricted and can only be given to a “U.S. Person,” which 
is a citizen of the United States, a lawful permanent resident alien of the U.S., 
or someone in the U.S. as a protected political asylee or under amnesty. The 
word “person” includes U.S. organizations and entities, such as companies or 
universities, see 22 CFR §120.15 for the full legal dehnition. Release of the 
high-energy, real-gas capability is further restricted because of International 
Traffic in Arms Regulations (ITAR). 

To request the Fun3D software suite, which will include the refine grid 
adaptation and mesh untangling library and the knife cut-cell library, please 
use the website request form available at 

http : //f unSd.larc. nasa.gov/chapter- l.html#request_fun3d 

or send an email to Fun3D-Support@lists . nasa . gov containing the following 

information: 

• “U.S. person” to put on agreement form, i.e., an institution or individual 

• Point of contact (if “U.S. Person” is not an individual) 

• Point of contact email address 

• Phone number, extension 

• FAX number (if available) 

• Address (PO boxes not allowed) 

• Proposed application^ (optional) 

• How did you discover Fun 3D? (optional) 

^The high-energy physics library that allows multiple species and non-equilibrium chem- 
istry are only included upon specific request — be sure to note that you desire access to 
this beta functionality as part of your application. Please include the phrase, “requesting 
high-energy gas libraries” . 
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We will forward your email to initiate a review by Langley software release 
authority (SRA) that verihes you qualify as a “U.S. Person.” Depending on 
the SRA’s backlog, you will be sent a software usage agreement form in a 
week or two. Once a completed usage agreement form is received and the 
SRA notihes the Fun3D support team, the Fun3D support team will make 
arrangements for transfer of the Fun3D software suite. 
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2 Conventions 


This chapter discusses the coordinate system orientation and nondimension- 
alization used by Fun 3D. The nomenclature for this section is 


a 

C 

e 

f 

h 

k 

L 

M 

P 

R 

Re 

t 

T 

U, V, w 
x,y,z 
a 

P 

7 

fi 

P 


Speed of sound 
Sutherland constant 
Energy per unit mass 
Frequency 

Enthalpy per unit mass 
Thermal conductivity 
Length 
Mach number 
Pressure 
Gas constant 
Reynolds number 
Time 

Temperature 

Cartesian components of velocity 

Cartesian directions 

Angle of attack 

Angle of sideslip 

Heat capacity ratio 

Viscosity 

Density 


where an asterisk (*) denotes a dimensional quantity. A subscript ref denotes 
a reference quantity. For fluid variables, such as pressure, ref usually corre- 
sponds to the value ‘at cx)’ for external flows or another condition for internal 
flows. The units of various reference quantities must be consistent. For exam- 
ple, if the reference speed of sound is dehned in feet/sec, then the dimensional 
reference length, L*ref, must be in feet. In what follows, Lj-ef is the length in 
the grid that corresponds to the dimensional reference length, L*ref] L^ef is 
considered dimensionless. 

Fun3D’s angle of attack, sideslip angle, and associated force coefficients 
are based on a body-hxed coordinate system: 

• positive X is toward the back of the vehicle; 

• positive y is toward the right of the vehicle; and 
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• positive z is upward 

as shown in Fig. 3. This differs from the standard wind coordinate system by 
a 180 degree rotation about the y axis. The a and [3 flow angle conventions 
are shown in Fig. 4. 



Figure 3: Fun 3D body coordinate system. 


Z 



Figure 4: Fun 3D freestream flow angle definition. 


2.1 Compressible Equations 

a: = x*l{L%,flLref) 

y ~ y / ref/Lref) 

Z = Z*l{L\,f/Lref) 

t = t*a%,f/{L%,f/Lref) 


P = P* Ip* ref Pref = 1 


20 


IV^I 

= \V*\/a*ref 


= Mref 

u 

= U*/a*ref 

Href 

= Mref COS a COS f3 

V 

= v*/a*ref 

Href 

= —Mref sin f3 

w 

= W*/a*ref 

Wref 

= Mref sin a cos f3 

P 

= P*/{p\efa*lef) 

Pref 

= 1/7 

a 

= a* /a* ref 

dref 

= 1 

T 

= T*/T*ref 

Tref 

= 1 

e 

= e*/{p\ef<ef) 

Href 

= 1/(7(7-1)) + M,V2 


To see how the nondimensional Navier-Stokes equations that are solved 
in Fun3D are obtained from their dimensional counterparts, it is sufficient 
to look at the unsteady, one-dimensional equations for conservation of mass, 
momentum, and energy: 


dp* d{p*u*) 
dt* dx* 


d{p*u*) d 
dt* dx* 



4 ^ du* 
3^ dx* 


0 


de* 

dt* 


d 

dx* 


{e*+p*)u* 



dT* 

k*—— 

dx* 


0 


where k* is the thermal conductivity. For a thermally and calorically perfect 
gas, we also have the equation of state, the dehnition of the speed of sound, 
and the specific heat relation: 


a 


*2 


Cp “I* Cy 


T* = 

p*R* 

^R*T* (7 = c//c/) 

R* R*/c; = (7 - l)/7 


The laminar viscosity is related to the temperature via Sutherland’s law 


p 


* 


F ref 


ref + V- 

T* + C* 



3/2 


where C* = 198. 6°R for air. 

Substitution of the nondimensional variables dehned above into the equa- 
tion of state and the dehnition of the speed of sound gives: 


T 



P 
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Sutherland’s law in nondimensional terms is given by 


^ 1 + C* /T*ref rpS /2 
^ T + C*/T\ef 

where C* is the Sutherland constant {C* = 198. 6°R for air) and where T*ref 
is in degrees Rankine. 

Substitution of the dimensionless variables into the conservation equations 
gives, after some rearrangement, 

^ d{pu) ^ 
dt dx 


d{pu) 

dt 


A 

dx 


pu +p- - 


4 M., 


ref 

3 Rei dx 


e/ 


= 0 


de 


A 

dx 


{e + p)u - - 


4 Mref du 


M, 


3 Rei 


-pu 


ref 


dT 


p- 


ref 


dx ReL.Rri'y - 1) dx 


= 0 


where Pr is the Prandtl number (generally assumed to be 0.72 for air) 


Pr = 



k* 


and where the Reynolds number per unit length in the grid, corre- 

sponds to the input variable reynoldsmumber in the funSd.nml hie. Rgl^^j: is 
related to the Reynolds number characterizing the physical problem, Re^Ve/ 
by 


Rei , = 

^ref 


P\ef\V*Lf{L%ef/Lref) _ 1 


P j.gj 


P ref 


-‘ref 


PeL\ 


■‘ref 


2.2 Incompressible Equations 

a; = X* / {L%,f / Lref) 

y ~ y / ref/Lref) 

Z = Z*l{L%,flLref) 

t =t*\VX^^/{L%,f/Lref) 



= \V\I\V'U, 

Vl„/ 

= 1 

u 


tlref 

= cos a cos /5 

V 

= «Vir-|„, 

^ref 

= — sin 

w 


Wref 

= sin a cos f3 

p 


Pref 

= 1 


22 



For incompressible flows, Fun 3D does not model any heat sources. The 
temperature T* is constant and so is the viscosity /i*. After dividing through 
by a constant reference density, the one-dimensional continuity and momentum 
equations are: 

du* _ ^ 
dx* 


du* <9 r ,2 P* ^ 

dt* dx* [ P*re/ 

The fundamental difference between the nondimensionalization of the com- 
pressible equations and the incompressible equations is that the sound speed 
is used in the former and the flow speed in the latter. Substitution of the 
dimensionless variables dehned above into the conservation equations gives, 
after some rearrangement, 

du 

dx 


du d 2 4 1 ( 9 m 

dt dx ^ 3 Rcl f dx 

L ■‘-'ref J 


0 


where, exactly the same as in the compressible-flow path, the Reynolds number 
per unit length in the grid is 


P* ref Lref 


2.3 Generic Gas Equations 

The generic gas path requires all reference quantities (velocity, density, temper- 
ature) be entered in the meter-kilogram-second (MKS) system. The transport 
property nondimensionalization includes the effects of rescaling using the grid 
length conversion factor. The nondimensionalization of other flow variables 
follows the practice used to derive the Mach number independence principle. 
Neither Mach number nor Reynolds number can be used to dehne reference 
conditions; these are derived from the fundamental reference quantities. The 
derived Reynolds number is relative to a one meter reference length. Tem- 
perature is never non-dimensionalized; it always appears in units of degrees 
Kelvin. 


p 

= P*/P*ref 

P'ref 

[kg/m' 

u 

= U*/V*ref 

KV 

[m/s] 

V 

= V*/V*ref 

rp^ 

-‘-ref 

|K] 

w 

= W*/V*ref 

T* 

^ref 

M 
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a = a* /V* ref 
P = P*/{p*refV*lef) 

e =e*/V*lf 
h =h*/V*lf 

2.4 Unsteady Flows 

One of the challenges in unsteady flow simulation is determining the nondi- 
mensional time step At. The number of time steps at that At necessary to 
resolve the lowest frequency of interest will impact the cost of the simulation 
and too large a At will corrupt the results with temporal errors. Time is 
non-dimensionalized within Fun3D by 

t = t* a* ref / {L* ref / Lref) (compressible) 

t = t*\V*\^^j/{L*ref/Lref) (iucompressible) 

where, as in the previous sections, quantities denoted with * are dimensional. 

In all unsteady flows, one or more characteristic times t*chr niay be identi- 
hed. In a flow with a known natural frequency of oscillation (e.g., vortex shed- 
ding from a cylinder), or in situations where a forced oscillation is imposed 
(e.g., a pitching wing), a dominant characteristic time is readily apparent. In 
such cases, if the characteristic frequency in Hz (cycles/sec) is f* chr) then 

t\hr = 

In other situations, no oscillatory frequency may be apparent (or not known 
a priori). In such cases, the time scale associated with the time it takes for 
a fluid particle (traveling at a nominal speed of \V*\^^j) to pass the body of 
reference length L*ref is often used: 

t\hr = L*refl\VX,f 

The corresponding nondimensional characteristic time is therefore given by: 

tc/ir t chr^ ref / ref / ^ref') (cOmpreSSible) 

tchr = t* chr\V*Xj / {L* ref / Lref) (iucompressible) 

Once the nondimensional characteristic tchr is determined, the user must 
decide on an appropriate number of time steps {N) to be used for resolving 
that characteristic time. Then the nondimensional time step may be specihed 
as: 

At = tehr / N 

The proper value of N must be determined by the user. However, a reasonable 
rule of thumb for second-order time integration is to take N = 200. Note that if 
there are multiple frequencies requiring resolution in time, the most restrictive 
should be used to determine At. 
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3 Boundary Conditions 

This chapter discusses the boundary conditions available in Fun3D. Table 1 
lists the integers used to specify Fun3D boundary conditions with a short 
description. Each grid description subsection in section 4 indicates how these 
integers are specified. Details of the boundary condition implementation are 
provided by Carlson. [5] Details of symmetry boundary conditions are provided 
in section 3.1. Some boundary conditions have required or optionally specified 
parameters defined in the feboundary .conditions namelist, see section B.4.16 
for further boundary condition details. 
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BC 

Table 1: 

Description 

Fun 3D boundary conditions. 
Notes 

-1 

Overlap 

overset grid boundary 

3000 

Tangency 

zero normal velocity, specified via fluxes 

4000* 

Viscous 

explicitly set the no-slip condition 

5000 

Farfield 

Riemann invariants 

5026 

Extrapolate 

supersonic outflow, variables extrapolated from the interior 

5050 

Freestream 

external freestream, specified via fluxes 

5051* 

Back pressure 

specified static pressure (switches to extrapolation boundary 
condition in the presence of supersonic flow) 

5052* 

Mach outflow 

static pressure outflow boundary condition set via a specified 
subsonic Mach number (not for boundary layer ingestion) 

6021 

Symmetry plane 1 

symmetry enforced by replacing x-momentum with zero ve- 
locity normal to arbitrary boundary plane. 

6022 

Symmetry plane 2 

symmetry enforced by replacing y-momentum with zero ve- 
locity normal to arbitrary boundary plane. 

6023 

Symmetry plane 3 

symmetry enforced by replacing z-momentum with zero ve- 
locity normal to arbitrary boundary plane. 

6100 

Periodicity 

discrete periodicity, limited to nominally 2D grids extruded 
across n planes in a third dimension 

6661 

X-symmetry plane 

enforces symmetry for x Cartesian plane 

6662 

F-symmetry plane 

enforces symmetry for y Cartesian plane 

6663 

Z-symmetry plane 

enforces symmetry for z Cartesian plane 

7011* 

Subsonic inflow 

subsonic inflow — Ptotal,plenum /p static, freestreamf 

Tt^bc — '^total,plenum/'^static, freestream) nozzlo Or tunnol 

plenum ( Wlinfiow < 1 ) 

7012* 

Subsonic outflow 

subsonic outflow {ptc — Pstatic^inlet /Pstatic^ freestream foi^ 

let flow (does not allow for reverse or supersonic flow at the 
outflow boundary face) 

7021* 

Reaction control jet plenum models the plenum of a reaction control system (RCS) Jet 

7031* 

Mass flow out 

specification of massflow out of the control volume 

7036* 

Mass flow in 

specification of massflow in to the control volume 

7100* 

Fixed inflow 

fixed primitive variables in to control volume 

7101* 

Fixed inflow profile 

specified profile 

7103* 

Pulsed supersonic inflow 

pulsing supersonic flow 

7104* 

Ramped supersonic inflow 

ramping supersonic flow 

7105* 

Fixed outflow 

specified primitive outflow conditions 


* See &boundary_conditions namelist in section B.4.16 to specify auxiliary information and for 
further descriptions. 
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3.1 X-Symmetry, y-Symmetry, and Z-Symmetry 

The symmetry condition in FUN3D enforces discrete symmetry. That is, if 
the mesh were mirrored about the symmetry plane and run as a full-span 
simulation, the residuals (and therefore the outputs, such as lift, drag, etc.) 
will be identical. The FUN3D automated tests include a case were a mirrored 
grid is compared to the symmetry boundary condition. Discrete symmetry is 
also enforced where multiple symmetry condition intersect (i.e., a corner of 
y-symmetry and Z-symmetry). 

Specifically, the condition enforces: 

• Any points on a symmetry plane are first “snapped” to the average 
coordinate for that plane. Many grid generators will have some small 
amount of “slop” in their y-coordinates for points on a y-symmetry plane; 
FUN3D immediately pops all of the points onto the exact same plane, 
at least to double precision. 

• The residual equation corresponding to the momentum normal to the 
symmetry plane is modified to reflect zero crossflow (i.e., pn = 0 on a 
y-symmetry plane). 

• The least squares system used to compute gradients for inviscid recon- 
struction to the cell faces is augmented to include symmetry contribu- 
tions across the symmetry plane (s). 

• All gradients of the velocity normal to the symmetry plane (v for a 
y-symmetry plane) in the source terms for the turbulence models are 
zeroed out. Gradients of the tangential velocities are zeroed out normal 
to the symmetry plane (du/dy, dw/dy). 

• No convective flux of turbulence normal to the symmetry plane. 

• Grid metrics (e.g., areas, normals) are forced to be symmetric at sym- 
metry planes. 
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4 Grids 


This chapter explains how to supply the proper file formats to Fun 3D, but 
does not cover how to create a mesh. See section 1.3 for grid generation 
guidance. Fun 3D supports a direct reader for many grid formats. The format 
of the grid is specihed in the &raw_grid namelist, section B.4.2. In addition to 
the directly read formats, translators are provided to convert additional grid 
formats into a format that can be read directly, see section 4.3. Fun 3D has the 
ability to apply rigid body rotations while reading the grid (see section B.4.4 
and section B.4.5) and mirror a grid about a symmetry plane (see section 4.5). 

4.1 File Endianness 

The ordering of bytes within a data item is known as “endianness.” If the 
endianness of a hie is different than the native endianness of the computer 
then a conversion must be performed. The endianness of each grid hie format 
is described in section 4.2. If your compiler supports it, Fun 3D will attempt 
to open binary hies with a open(convert=...) keyword extension. Consult the 
documentation of the Fortran compiler you are using to determine if other 
methods are available. For example, with the Intel® Fortran compiler, the en- 
dianness of hie input and output can be controlled by setting the F_UFMTENDIAN 
environment variable to big or little. 

4.2 Supported Grid Formats 

Fun 3D natively supports the grid formats summarized in Table 2. 


Table 2: File extensions. 


Format 

Grid files 

BC File 

AFLR3 

.ugrid 

.mapbc 

FAST 

.fgrid 

.mapbc 

FieldView 

.fvgrid_fmt 

.mapbc 


.fvgrid_unf 

.mapbc 

FUN2D 

.faces 

.mapbc 

.mapbc 

VGRID 

.cogsg, .be 

FELISA 

.gri, .fro 

.bco 


* Same suffix, but GridTool format. 


The standard Fun 3D .mapbc hie format contains the boundary condition 
information for the grid. The hrst line is an integer corresponding to the num- 
ber of boundary groups contained in the grid hie. Each subsequent line in this 
hie contains two integers, the boundary face number and the Fun 3D bound- 
ary condition integer; these numbers may optionally be followed by a character 


string that specifies a “family” name for the boundary. The family name is 
required if the patch_lumping option (section B.4.2) is invoked to combine 
patches into fewer patch families. Below is a sample .mapbc file illustrative for 
all grid formats except GridTool/VGRID, FELISA, and FUN2D, which are 
described later. 
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1 

6662 

box_ymin 

2 

5025 

box_zmax 

3 

5050 

box_xmin 

4 

5025 

box_ymax 

5 

5025 

box_zmin 

6 

5025 

box_xmax 

7 

3000 

wing_upper 

8 

3000 

wing_lower 

9 

3000 

wing_upper 

10 

3000 

wing_upper 

11 

3000 

wing_lower 

12 

3000 

wing_lower 

13 

3000 

wing_tip 

4.2.1 

AFLR3 Grids 


AFLR3, SolidMesh, Pointwise, and GridEx can all produce this format and 
Fun3D ships with translators that convert Plot3D and GGNS grids to AFLR3 
format. The format is documented online at http : / / simcenter.msstate.edu/ 
docs/solidmesh/ugridf ormat.html 

AFLR3 grid file format types are indicated by file suffixes. The formatted 
(plain text) style has a .ugrid suffix while other types vary according to endi- 
anness (see section 4.1) and binary type as shown in Table 3. The boundary 


Table 3: AFLR3 non-ASCII grid suffixes. 

Type Little endian Big endian 

Fortran Stream, C Binary .IbS. ugrid .b8. ugrid 
Fortran Unformatted .lr8. ugrid .r8. ugrid 

conditions are specified via the standard Fun3D .mapbc format. 

4.2.2 FAST Grids 

The .fgrid file contains the complete grid stored in ASGII FAST format. 
The format is documented online at http://simcenter.msstate.edu/docs/ 
solidmesh/FASTf ormat.html The boundary conditions are specified via the 
standard Fun 3D .mapbc format. 
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4.2.3 VGRID Grids 


The .cogsg file contains the grid nodes and tetrahedra stored in unformat- 
ted VGRID format. The VGRID cogsg files always have big endian byte 
order regardless of the computer used in grid generation. See section 4.1 for 
instructions on specifying file endianness. 

The .be hie contains the boundary information for the grid, as well as a hag 
for each boundary face. For viscous grids with a symmetry plane, VGRID 
is known to produce boundary triangles in the .be hie that are incompatible 
with the volume tetrahedra. Fun 3D provides a repair_vgridnnesh utility to 
swap the edges of these inconsistent boundary triangles. If Fun 3D reports 
that there are boundary triangles without a matching volume tetrahedra, use 
this utility. 

VGRID has a diherent .mapbe boundary condition format. For each 
boundary hag used in the .be hie, the .mapbe hie contains the boundary type 
information. The VGRID boundary conditions are described at the website: 
http://tetruss.larc.nasa.gov/usm3d/be.html. The Fun3D boundary con- 
dition integers can also be used in place of the VGRID boundary condition 
integers. Internally, Fun3D converts the VGRID boundary condition inte- 
gers to the Fun3D boundary condition integers as indicated in Table 4. 

Table 4: Boundary type mapping between VGRID and Fun3D. 

VGRID FUN3D 

-1 -1 

0 5000 

1 6662 

2 5005 

3 5000 

4 4000 

5 3000 

44 4000 

55 3000 


4.2.4 FieldView Grids 

The .fvgrid_fmt hie contains the complete grid stored in ASCII FieldView 
FV-UNS format, and the .fvgrid_unf hie contains the complete grid stored 
in unformatted FieldView FV-UNS format. Supported FV-UNS hie versions 
are 2.4, 2.5, and 3.0. With FV-UNS version 3.0, the support is only for the 
grid hie in split grid and results format; the combined grid/results format 
is not supported. Fun3D does not support the arbitrary polyhedron ele- 
ments of the FV-UNS 3.0 standard. For ASCII FV-UNS 3.0, the standard 
allows comment lines (line starting with !) anywhere in the hie. Fun3D 


30 


only allows comments immediately after line 1. Only one grid section is al- 
lowed. The precision of the unformatted grid format should be specified by 
the f ieldview_coordinate_precision variable in the &raw_grid namelist, 
see section B.4.2. The boundary conditions are specified via the standard 
Fun 3D .mapbc format. 


4.2.5 FELISA Grids 

The .gri file contains the grid stored in formatted FELISA format. [6] The 
.fro file contains the surface mesh nodes and connectivities and associated 
boundary face tags for each surface triangle. This file can contain additional 
surface normal or tangent information (as output from GridEx or SURFACE 
mesh generation tools), but the additional data is not read by Fun3D. The 
.bco hie contains a hag for each boundary face. If original FELISA boundary 
condition hags (1, 2, or 3) are used, they are translated to the corresponding 
Fun3D 4-digit boundary condition hag according to Table 5. Alternatively, 
Fun3D 4-digit boundary condition hags can be assigned directly in this hie. 


Table 5: Boundary type mapping between FELISA and Fun3D. 

FELISA FUN3D 

1 3000 

2 6662 

3 5000 


4.2.6 Fun 2D Grids 

The .faces hie contains the complete grid stored in formatted Fun2D format 
(triangles). Internally, Fun3D will extrude the triangles into prisms in the 
^/-direction and the 2D mode of Fun3D is automatically enabled. Output 
from the how solver will include this one-cell wide extruded mesh. 

Boundary conditions are contained in the Fun2D grid hie as integers 0- 
8. The mappings to Fun3D boundary conditions are given in Table 6. If 
Fun3D does not detect a .mapbc, it will write a .mapbc hie that contains the 
default Table 6 mapping. If you wish to change the boundary conditions from 
the defaults based on the .faces hie, simply edit them in this .mapbc hie and 
rerun Fun3D. The boundary conditions in the .mapbc hie have precedence 
over the .faces boundary conditions. If you wish to revert to the boundary 
conditions in the .faces hie after modifying the .mapbc, you can remove the 
.mapbc and rerun Fun3D. 
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Table 6: Boundary type mapping between Fun2D and Fun3D. 

FUN2D FUN3D 

0 3000 

1 4000 

2 5000 

3 -1 

4 4010 

5 4010 

6 5005 

7 7011 

8 7012 

4.3 Translation of Additional Grid Formats 

While Fun 3D supports the direct read of multiple formats, utilities are pro- 
vided to translate additional grid formats into a format that Fun 3D can read. 

4.3.1 PLOT3D Grids 

The utility plot3d_to_af lr3 converts a PLOT3D structured grid to an AFLR3- 
format hexahedral unstructured grid. The original structured grid must be 
3D multiblock http://www.grc.nasa.gov/WWW/wind/valid/plot3d.html (no 
iblanking) with the file extension .p3d for formatted ASCII or the the file ex- 
tension .uf mt for Fortran unformatted. Only one-to-one connectivity is allowed 
with this option (no patching or overset). The grid should contain no singular 
(degenerate) lines or points. A neutral map file with extension .nmf is also re- 
quired. This file gives boundary conditions and connectivity information. The 
.nmf file is described at http://geolab.larc.nasa.gov/Volume/Doc/nmf.htm. 

Note that the Type name in the .nmf file must correspond with one of 
Fun3D’s BC types, plus it allows the Type one-to-one. If the Type is not 
recognized, you will get errors like: 

This may be an invalid BC index. 

An example .nmf file is shown here for a simple single-zone airfoil C-grid 
(5 X 257 X 129) with six exterior boundary conditions and one one-to-one 
patch in the wake where the C-grid attaches to itself: 


Neutral 

Map File generated by the V2k software of 

NASA 

Langley's GEOLAB 

Block# IDIM 

JDIM KDIM 



1 

1 5 

257 129 



Type 

B1 FI SI El S2 E2 B2 F2 SI 

El 

S2 E2 Swap 
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'teLQgency' 
'tangency' 
'farfield_extr' 
'farfield_extr' 
' one-to-one ' 

' viscous_solid' 
' f arf ield_riem' 


1 3 1 257 1 129 

1 4 1 257 1 129 

1 5 1 129 1 5 

1 6 1 129 1 5 

111 5 1 41 1 1 1 5 257 217 false 

111 5 41 217 

12 1 5 1 257 


4.3.2 CGNS Grids 

Fun3D is distributed with a utility cgns_to_af lr3 that converts CGNS hies 
http://cgns.sourceforge.net/ to AFLR3 grids. This utility will only be 
built if Fun3D is conhgured with a CGNS library, see section A. 7. 12. Only 
the Unstructured type of CGNS hies are supported. The following CGNS 
mixed element types are supported: PENTA_6 (prisms), HEX_8 (hexes), TETRA_4 
(tets), and PYRA_5 (pyramids). 

The CGNS hie must include Elements_t nodes for all boundary faces (type 
QUAD_4 or TRI_3) to refer to the corresponding boundary elements. Otherwise, 
the utility cannot recognize what boundaries are present because it currently 
identihes boundaries via these 2D element types. The cgns_to_af lr3 utility 
requires that the BC elements be listed either as a range or a sequential list. 

It is also helpful to have separate element nodes for each boundary element 
of a given BC type. This way, it is easier to interpret the boundaries, i.e., body 
versus symmetry versus farheld. Visualization tools, such as Tecplot™, can 
easily distinguish the various boundary condition groups as long as each group 
has its own node in the CGNS tree. Under BC_t, cgns_to_af lr3 reads these 
BC names, but ignores additional boundary data (e.g., BCDataSet, BCData). 


Table 7: Boundary type mapping between CGNS and Fun3D. 
CGNS FUN3D 


BCSymmetry Plane 
BCFarfield 
BCWallViscous 
BCWall 

BCWallInviscid 

BCOutflow 

BCTunnelOutflow 

BCInflow 

BCTunnelInflow 


6661, 6662, or 6663 via prompt 

5000 

4000 

4000 

3000 

5026 

5026 

5000 

5000 


If the CGNS hie is missing BCs (no BC_t node), cgns_to_af lr3 still tries 
to construct the BCs based on the boundary face Element s_t information. If 
these boundary element nodes have a name listed in Table 7, a .mapbc hie 
will be written that contains the Fun3D boundary condition numbers. If the 
name is not recognized, you will see the message: 

WARNING: BC type ... in CGNS file not recognized. 
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in which case you will need to hx it by by editing the .niapbc hie manually. 
Always check the .mapbc hie after the utility has run, to make sure that the 
boundary conditions have all been interpreted and set correctly. If a trans- 
lation problem is observed, you should edit the .mapbc hie before running 
Fun3D. 

4.4 Implicit Lines 

The standard implicit solution relaxation scheme in Fun 3D is a point-implicit, 
which inverts the linearization of the residual at each node to compute an up- 
date to the solution. A line-implicit relaxation scheme can be used that inverts 
the linearization of a line of nodes simultaneously. Typically, lines are con- 
structed for the subset of nodes in the boundary layer to address the stihness 
inherent in the Navier-Stokes equations on anisotropic grids. Therefore, the 
use of line-implicit relaxation may improve the convergence of viscous how sim- 
ulations. These lines are used in conjunction with the standard point-implicit 
relaxation scheme. Detailed descriptions of both line and point relaxation 
schemes are provided by Nielsen et ah [7] Currently, every viscous boundary 
node must have one and only one associated implicit line. Lines of nodes 
are specihed in a formatted hie with the suffix .linesAmt that contains the 
dehnitions of lines emanating from viscous boundary nodes as a list of node 
numbers. The format of the .lines_fmt hie is 

[total number of lines] [total number of points in lines] 

[min points in a line] [max points in a line] 

[points in line 1] 

[first node of line 1] 

[last node of line 1] 

[points in line 2] 


4.5 Grid Mirroring 

A half computational domain with a symmetry plane can be mirrored to form 
a complete domain. This is a common use case for rehecting half of an aircraft 
conhguration to form a full-span conhguration to include the ehects of side 
slip. Use the --mirror_x, --mirror_y, or --mirror_z command line options 
(section 5.2) to rehect the domain and remove the boundary patch located 
at a; = 0, ?/ = 0, or t = 0, respectively. When one or more of these mirror 
command line options are provided, Fun 3D will start execution on a grid that 
is mirrored internally during grid processing. The symmetry plane boundary 
face patch will be removed and each non-symmetry face patch will duplicated 
about the symmetry plane. These operations on boundary face patches will 
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alter the numbering of patches. Therefore, the boundary face indexes used 
to specify boundary conditions and co-visualization will be modihed to track 
these changes. The user is required to update the indexes in these namelists 
appropriately. The hie [project_rootname] _mirror*.mapbc will be created 
in the current directory to aid this process. 

The internally mirrored grid will be discarded when execution is complete. 
So, provide the same mirror command line option to any restarted execu- 
tions. Alternatively, the --write_mesh [new_project] command line option 
is available to export the mirrored grid. Utilizing this exported grid would 
remove the need for the mirror command line option on subsequent runs. 
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5 Flow Solver, NODET 

This chapter covers what is required to run an initial flow solution, how to 
restart a flow solution, and how to specify what outputs the solver nodet 
produces. 

5.1 Flow Solver Execution 

The grid and flow conditions are specified in the file funSd.nml; see section B.4 
for the file description. If you configured Fun 3D without MPI, the executable 
is named nodet. If you configured Fun 3D with MPI, the executable is named 
nodetnnpi. Configuration and installation is explained in detail in section A. 
The executable nodet can be invoked directly from the command line, 

nodet [funSd options] 

but the MPI version nodet jnpi will need to be invoked within an MPI envi- 
ronment. The most common method is via 

[MPI run command] [MPI options] nodet_mpi [funSd options] 

The details of the MPI run command and MPI options will depend on the MPI 
implementation. The MPI run command is commonly mpirun or mpiexec. 
The MPI options may contain the number of processors -np [n] , a machine 
file -machinef ile [file] , or no local -nolocal. If a queuing system is used 
(e.g., PBS) this command will need to be run inside an interactive job or a 
script. See your MPI documentation or system administrator to learn the 
details of your particular environment. 

If you have provided a grid with boundary conditions and funSd.nml, you 
will then see the solver start to execute. If an unexpected termination happens 
during execution, especially during grid processing or the first iteration, you 
may need to set your shell limits to unlimited, 

$ ulimit unlimited # for bash 
$ unlimit # for c shell 

A detailed description of the output files is given below. 

5.2 Command Line Options 

These options are specified after the executable. The majority of the command 
line options are functionality under development and there is work underway to 
migrate command line options to namelists. Namelists are the preferred input 
method. Command line options should be avoided unless they are the only 
way to activate the functionality you require. These commands are always 
preceded by -- (double minus). More than one option may appear on the 
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command line (each option proceeded by a -- ). You can see a listing of the 
available command line options in any of the codes in the Fun 3D suite by 
using the command line option --help after the executable name, 

. /nodet_mpi — help 

The options are then listed in alphabetical order, along with a short de- 
scription and a list of any auxiliary parameters that might be needed, and 
then the code execution stops. Specihc examples of the use of command line 
options are found throughout this, and later, chapters. 

5.3 Output Files 

These are the output hies produced by the how solver, nodet. 

[project_rootname] .f low This hie contains the binary restart infor- 
mation and is read by the solver for restart computations. See the restart _read 
namelist variable in section B.4.13 to control restart behavior. 

[project_rootnamel_hist.dat This hie contains the convergence his- 
tory for the RMS residual, lift, drag, moments, and CPU time, as well as the 
individual pressure and viscous components of each force and moment. The 
hie is in Tecplot™ format. See section B.4.20 for an improved method to track 
forces and moments. 

[pro j ect_rootname] _subhist.dat For time accurate computations only. 
This hie contains the sub-iteration convergence history for the RMS residuals. 
The hie is in Tecplot™ format. 

[project_rootname] .forces This hie contains a breakdown of all the 
forces and moments acting on each individual boundary group. The totals for 
the entire conhguration are listed at the bottom. See section B.4.20 for an 
improved method to track forces and moments. 

5.3.1 Flow Visualization 

There are four basic categories of output: boundary data, sampling data (on 
entities such as planes, boxes and spheres), volumetric data, and slice data 
controlled by the namelists in Table 8. 

Each namelist has a corresponding frequency variable, A positive frequency 
will cause the output to be generated every frequency time step/iteration. A 
negative frequency will cause output to be written only at the end of a run. A 
zero frequency (the default) with produce no output. See the corresponding 
namelist descriptions for details. 
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Table 8: Solver output types. 

Type Namelist 


domain boundaries 
domain volume 
boundary slices 
various geometries 

point 


feboundary .output .variables 
fevolume. output .variables 
feslice.data 

fesampling.parameters and 
fesampling.output .variables 
fesampling.parameters and 
fesampling.output. variables 


section B.4.24 
section B.4.23 
section B.4.27 
section B.4.26 and 
section B.4.25 
section B.4.26 and 
section B.4.25 


5.3.2 Flow Visualization Output Prom Existing Solution 

If a Fun3D flow solution already exists, visualization files can be produced 
by setting steps = 0 or steps = 1 in the &code_run_control namelist (sec- 
tion B.4.13) and setting the restart_read variable to something other than 
’off’. One iteration is required to compute gradient quantities (i.e., skin 
friction). This will allow generation of visualization output without having to 
repeat the entire calculation. 
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6 Adjoint Solver, DUAL 

This section describes how to execute the adjoint solver, dual, directly. Typ- 
ically, DUAL is executed by scripts that manage the multiple steps required 
for design optimization (section 9) or grid adaptation (section 8). However, 
it may be necessary to run dual directly to diagnose problems or gain expe- 
rience during setup including determining input parameters and termination 
strategies. Fun3D is conhgured to compile dual by default. While the ad- 
joint method is available for most commonly used Fun3D capabilities, only a 
subset of Fun3D’s full capabilities are implemented in the adjoint solver. 

6.1 Convergence of the Linear Adjoint Equations 

The adjoint solution is dependent on the primal flow solution (and the con- 
vergence of the primal flow equations). While the primal solution may have 
converged enough to give acceptable force and moment results, the flow resid- 
uals might still be large, which can cause the adjoint solution scheme to di- 
verge. This divergence issue is most common in turbulent simulations. A 
divergent adjoint scheme can be improved in some circumstances with the 
— outer_loop_krylov command line option. It is critical to run the flow 
solver and the adjoint solver with the same governing equations and bound- 
ary conditions. 

The scaling of the adjoint residuals is different from the flow residuals 
and is dependent on the choice of the adjoint cost functions. The number of 
iterations steps and the residual tolerance stopping_tolerance will need to 
be adjusted, see section B.4.13. The sensitivities should converge at the same 
rate as your functions (i.e., lift), but an adjoint with some algebraic error may 
still provide reasonable sensitivities for design and grid adaptation. 

6.2 Required Directory Hierarchy and Executing dual 

The executable dual can be invoked directly from the command line, 
dual [funSd options] 

but the MPI version dual_mpi will need to be invoked within an MPI envi- 
ronment. The most common method is via 

[MPI run command] [MPI options] dual_mpi [funSd options] 

Any [funSd options] provided to NODET that control the flow solver residual 
will also be required for the adjoint solver for a consistent adjoint solution and 
solution scheme. See the flow solver execution instructions for more details, 
section 5.1. 
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DUAL expects the cost function description ../rubber. data to be in the 
parent directory of the directory from which it is invoked. The input and 
flow restart hies are shared with nodet in the directory ../Flow/. The how 
solver must be run to completion, to provide a how restart hie, before dual 
is invoked. See Table 9 for the required hies and locations. 


Table 9: Adjoint solver dual directory hierarchy. 

Relative Path Description 

../Flow/ [pro ject_rootname] .flow Primal how solution (restart) 

../Flow/fun3d.nml Main input namelist hie 

../rubber. data Description of the adjoint cost function 


6.3 rubber. data 

The minimum required rubber. data for running the adjoint (and grid adap- 
tation) can be written with the command 

f3d function [cost function name] 

Available cost function names are discussed in section 9.1 and listed in Ta- 
ble 10. See section 9.6.2 for complete details on this hie format including the 
information required for design. The rubber. data reader requires the exact 
number of header lines. Be very careful when editing this hie. 

6.4 Output Files 

The adjoint solver will export visualization hies in the same manner as the 
how solver when requested, see section 5.3.1. 

[project_rootname] .adjoint This hie contains the binary restart in- 
formation and is read by the and adjoint solver for restart computations. 

[project_rootname] Tiist.tec This hie contains the convergence his- 
tory for the RMS residual of the adjoint equations and CPU time. The hie is 
in the same Tecplot™ format as the how solver produces. History information 
is truncated when the adjoint solver is restarted. 
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7 Grid Motion 


Fun 3D has an extensive capability for grid motion. Grid motion may be 
rigid, where points in the grid move in nnison, or grid motion may resnlt from 
elastic deformation of the grid to follow the motion of one or more bonndaries 
in the domain. To accommodate both types of grid motion, a distinction is 
made between ‘body motion’ and ‘grid motion’. The user begins by dehning 
one or more bodies (a body being a collection of one or more boundary patches 
in the grid), and specihes how that body is to move. This section describes 
how to specify the motion of each body as rigid motion, elastic motion, or 
a combination of rigid and elastic motions. The motion and deformation of 
volume grid surrounding the bodies is controlled through the concept of mesh 
movement (see section 7.2). 

Motion requires the introduction of reference frames. Fun 3D solves the 
flow equations in an inertial reference frame (one exception to this, section B.4.8, 
can not be used with grid motion). Each moving body has its own reference 
frame; the body frame is taken to coincide with the inertial reference frame 
at f = 0. In addition to the inertial and body reference frames that are au- 
tomatically bookkept when grid motion is activated, the user may dehne an 
‘observer frame’ for visualization output. Typically, the ‘observer frame’ is 
either the inertial frame (default) or one of the moving body frames. There is 
the provision for the observer frame to move independently, if required. 

Fun 3D allows for hierarchical (parent/child) body motions in which the 
motion of one body follows the motion of another body. The top level of these 
hierarchical motions is the inertial frame, and the default parent frame of any 
moving body is taken as the inertial frame (i.e., by default the motion of a 
body is assume to be relative to the inertial frame). 

For all but a few specialized capabilities discussed below (see section 7.5), 
grid motion requires that Fun 3D be executed in ‘time-accurate’ mode (see 
section B.4.14). To activate grid motion, the input variable moving_grid = 
.true, in the feglobal namelist is required. Finally, an additional input hie, 
mo ving_body. input, is needed to establish the details of the motion (see sec- 
tion B.5). 

Any grid motion that the user specihes leaves the original grid file unaltered. 
Grid motion always starts from the input grid set in the &raw_grid namelist 
(see section B.4.2). The Fun 3D restart hie contains enough information so 
that motion can be continued seamlessly through restarts. If the user would 
like to obtain a new grid hie with the grid in its position at the end of the 
execution, use the command-line option --write nnesh [new_pro j ect] , where 
[new.project] is the project name of the new grid hie. Note that regardless 
of the grid format of the original mesh, the new mesh format will be in AFLR 
stream format (bS.ugrid). 

The distance function needed for any turbulence model is computed once 
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by default, based on the input grid. If the entire grid is moved rigidly, the 
distance function remains unchanged with motion. However, for deforming 
grids and (to a lesser extent) rigid overset grids, the distance from a point 
to the nearest surface may change to some extent as the grid is moved from 
the initial state. For deforming meshes, the grid points nearest to the sur- 
face behave as a nearly rigid grid, so the effect on the distance function is 
minimal. Currently, it is up to the user to decide if the extra cost of re- 
computing the distance function is justihed. As dehned in section B.4.22, 
setting recompute_turb_dist = .true, will force the distance function to be 
recomputed every turb_dist_update_f req time steps when grid motion is ac- 
complished by deformation, or if overset grids are used. The distance function 
is never recomputed for rigid meshes that do not require overset connectiv- 
ity. These same distance function considerations also apply to the specialized 
capabilities discussed in section 7.5. 

7.1 Overview of moving_body. input 

Moving-grid cases require the moving_body. input input hie. Complete details 
are provided in section B.5 and an overview is proved here. Within this hie, ba- 
sic information required for all moving-grid cases is accomplished through the 
&body_def initions namelist (see section B.5.1). Depending on the the type of 
‘motion driver’ selected (i.e. how the body is to be moved), additional namelist 
input is usually required. The &f orcednnotion namelist (See section B.5. 2) 
allows the user to specify constant translation and/or rotational motion of 
a body. The &motion_f rom_f ile namelist (see section B.5. 4) specihes body 
motion by providing a time sequence of 4 x 4 transform matrices, and is the 
most general means of specifying rigid-body motion. The &observer_motion 
namelist (see section B.5. 3) allows the user to specify motion of an ‘observer’ 
reference frame. Visualization (see section 5.3.1) is in the ‘observer’ frame. 

7.2 Choosing the Type of Mesh Movement 

The user must choose a means to move the mesh that will accommodate 
the prescribed or calculated body motion. As described in section B.5.1, 
the choices are meshnnovement = ‘ rigid’ , meshnnovement = ‘ deform’ , or a 
combination of the two (e.g. meshnnovement = ‘ rigid+def orm’ . Whenever 
possible, the most robust and fastest executing option is ‘rigid’, since rigid 
motion is quickly and efficiently applied via a 4 x 4 transform matrix (see 
section 7.3) and is guaranteed to maintain positive cell volumes as the mesh 
is moved. Mesh deformation, on the other hand, increases the computational 
time as it requires the solution of an additional system of partial differential 
equations (linear elasticity). Furthermore, there is no guarantee of positive cell 
volumes after deformation. Fun 3D will automatically try to £x negative vol- 
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umes during deformation, but this is rarely successful. Execution terminates 
when negative cell volumes are encountered and cannot be remedied. 

Elastic body deformations of the preclude purely rigid grid motion (i.e., the 
body itself undergoing deformation, as occurs for aeroelastic bodies). However, 
some cases can beneht from the combination of rigid and deforming mesh mo- 
tion. This can allows large-scale motion to be described as rigid motion and 
reduces the magnitude of the elastic deformation to smaller-scale motions. 
Reducing the magnitude of body elastic motions can reduce the cost of com- 
puting the elastic deformation of the adjacent volume grid. Smaller elastic 
deformations also increase the robustness by reducing the likelihood of gener- 
ating negative volumes. An example of combined rigid and elastic deformation 
is a rotor blade of a rotorcraft simulation, where rigid motion is used to rotate 
the blades around the shaft axis and elastic deformation is used to deform the 
the blade under aerodynamic loading. 


7.3 4x4 Transform Matrices 

All rigid motions (body and/or grid) within Fun3D are accomplished via ap- 
plication of 4 X 4 matrices to describe affine transformations. [8] These trans- 
forms map a body/grid from the position at t = 0 to the current position at 
t = T. The inverse of these transforms are used to map a body/grid from 
its current position back to its position at t = 0. Although the user usually 
does not need to know the details of these transform matrices to use the grid 
motion capability in Fun3D, they are described below for reference. 

The 4x4 transform matrices contain both translation and orthonormal 
rotation components. Given a point at an initial position {x, y, z)'^ , application 
of the transform matrix moves the point to its new position 
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where the 3x3 submatrix entries in the upper left dehne an orthonormal 
rotation about the origin, (0, 0, 0)^, and the last column dehnes a translation. 
The last row is always set as (0, 0, 0, 1)^. Application of the inverse of this 
transform matrix moves the point back to the initial position. 

Two often-encountered transforms are a pure translation from the origin 
to a point {xo,yo, Zq)'^ and a pure rotation 9 in the direction n (unit vector) 
about the origin 
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[To] 


1 0 0 Xo 

0 1 0 I/O 

0 0 1 2:0 

0 0 0 1 


[Ro] = 

where s6 = sin(0) and c6 = cos{6). The right-hand rule in the direction of 
n dehnes the sense of 6. Other forms of the 3x3 rotation submatrix may 
arise depending on how the motion is specihed (e.g., chained rotations such as 
Euler angles). Note that [To]“^ is simply [To] with {xo,yo, zq)'^ replaced by 
{-xo, -yo, -zoV, and maps (xq, yo, zqY to the origin. 

An extremely useful feature of the transform matrix approach is that multi- 
ple transformations telescope via matrix multiplication. Thus, rotation about 
a point {xq, yo, zq)'^, by an angle 9, in the direction n is effected by first trans- 
lating to the origin, performing the rotation, and then translating back to 
{xo,yo, zo)'^ , which is accomplished via three matrix multiplications to give 
the complete transform matrix [T] 

[T] = [T„][R„]|T„]-‘ 

The telescoping property of the transform matrices is also useful for track- 
ing motions of one body relative to another. For example, a wing may be 
translating up and down, while at the same time, a flap may be pitching 
about a hinge line hxed on the wing. It is natural to describe the pitching 
motion of the flap in its own coordinate system, which at t=0 is the same as 
the wing coordinate system. If the transform matrix describing the plunging 
of the wing relative to its initial position in an inertial reference frame is given 
by [T]wing, and the transform matrix of the pitching motion of the flap relative 
to a hinge line dehned in the flap coordinate system is given by [T]fiap, then 
the position of the flap, relative to the inertial frame, may by computed using 
the composite transform 


(1 — c9)nx^ + c6 
(1 — c9)nxny + Uzsd 
(1 — c9)rixnz — UysO 
0 


(1 — c9)nxny — Uzsd 

(1 — c9)ny^ + c9 
(1 — c9)nyUz + Uxs9 
0 


(1 — c6)nxnz + UysO 0 
(1 — c9)nynz — Uxs9 0 
(1 - c9)nz^ + c9 0 
0 1 


[T] — [T] wing [T] flap 

The order of matrix multiplication is important: post multiplication of the par- 
ent transform takes coordinates from the child system into the parent system, 
which is then moved relative to the inertial frame according to the parent 
transform. The example above is for a simple, one-generation, parent-child 
composite motion, but the concept may be extended to any number of gener- 
ations. 
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7.4 Verifying Grid Motion Inputs 


When setting up a moving-grid case, it is usually a good practice to verify that 
the desired grid motion will be performed before an attempt is made with a 
large and potentially expensive time-dependent flow solution. There are two 
options that may be used to check that the motion setup is correct; both must 
be used in conjunction with boundary output to be useful (see section 5.3.1). 
Both options bypass the flow-solution but not the grid-motion mechanics. Be- 
cause these options decouple the flow solution and the grid motion, they are 
generally restricted to cases in which the motion is prescribed by the user. 
If the motion results from aerodynamic loading, such six degrees of freedom 
motion or as a result of aeroelastic deformation, there is no complete check 
but to run the coupled simulation. However, it may be possible to prescribe 
a motion that is similar to the expected motion so that body definitions and 
time step sizes may be verified prior to the coupled solution. 

The first option is enabled by setting body_motion_only = .true, in the 
feglobal namelist. As the name of the option implies, only the user-dehned 
bodies are moved, not the entire mesh. This is the quickest check, especially 
for deforming meshes, since the elasticity equations are not solved. Volume 
and surface elements adjacent to the moving bodies will likely become inverted 
during this test. So, expect to see inverted elements in visualization of output 
grids on symmetry boundaries, farfield boundaries, sampling planes, etc. 

The second option is more discriminating for deforming grids, and is en- 
abled by setting gridnnotion.only = .true, in the feglobal namelist. This 
option runs through the entire grid-motion mechanics, including solution of 
the linear elasticity equations for deforming grids. This will significantly in- 
crease the computational time for this check compared to bodyunotion_only 
= .true.. For deforming meshes, this option will indicate whether or not the 
mesh will survive the prescribed motion without negative volumes. All visual- 
ization options can be used with this option to observe the surface and volume 
grid deformation. 

Because body_motion_only = .true, option is fairly quick even for deform- 
ing meshes, the recommended approach for deforming meshes is to do start 
with body_motion_only = .true, to verify that the body moves as desired. 
After the basic motion is verified, the gridunotion_only = .true, can be ex- 
ercised, to ensure the deformation will be successful as the body executes its 
motion. Both body and grid motion are fast for rigid meshes. 

For periodic motions it is strongly recommended to verify that the bodies 
return to their initial position after the expected number of time steps. Failure 
to return to the initial position at the expected time likely indicates an error 
in the input time step or the nondimensional frequency. Insufficient numerical 
precision of the input values of these quantities can prevent a return to the 
initial position after one period. 
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7.5 Static Grid Manipulations 

Several options available to move or deform the grid during pre-processing 
are not considered ‘moving grid’ options. Therefore, these static grid manip- 
ulations do not require the code to be run in a time-accurate manner, the 
moving_body. input hie, or moving_grid = .true, in the feglobal namelist. 
These static manipulations result in a one time movement of the mesh at 
the start of the code execution. As with moving grids, the original grid 
hie specihed in the &raw_grid namelist (see section B.4.2) remains unal- 
tered. The body_motion_only or grid_motion_only options do not apply to 
these static grid manipulations. As for time-accurate moving grids, the rigid- 
grid option (&grid_transf orm) is preferred over the deforming grid option 
(febody .transform) whenever possible because it is less expensive and more 
robust. 

7.5.1 Grid Transform 

This static grid manipulation is governed by the &grid_transf orm namelist in 
the funSd.nml hie (see section B.4.4). It allows the entire grid to be rotated, 
translated, or scaled with a few simple inputs. A more general manipulation 
of the grid may be obtained through the input of a 4 x 4 transform matrix. 

7.5.2 Body Transform 

This static grid manipulation is governed by the &body .transform namelist 
in the funSd.nml hie (see section B.4.5). It allows user-dehned bodies to 
be rotated or translated (but not scaled). An example would be to make 
a small change to the angle of a hap, while leaving the orientation of the 
wing unchanged. The namelist allows for one or more bodies to be dehned 
as collections of one or more boundaries in the grid, where each body may 
be manipulated independently of the others. As with the fegrid.transf orm 
option, a 4 X 4 transform matrix may be input if the simple rotation and 
translation options provided by the namelist input are insufficient to describe 
the transform. When this option is used, the specihed bodies will be moved 
according to the input, and the mesh will be deformed to accommodate the 
new body positions. 
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8 Grid Adaptation 


Fun 3D implements metric-based adaptation, where grid adaptation is sepa- 
rated into two tasks. The hrst step is to construct a metric that describes the 
desired size and anisotropy of the adapted grid elements. The second step is 
to produce an adapted grid that is based on this metric. 

Feature-based adaptation constructs the metric based on properties of the 
flow solution. Adjoint-based adaptation constructs the metric from the flow 
and adjoint solutions to reduce estimated errors in a specihed output function. 
The namelist &adapt_metric_construction (section B.4.30) for specifying de- 
tails of the metric. 

Fun3D supports a number of grid adaptation libraries. The namelist 
feadapt .mechanics (section B.4.31) specihes the grid adaptation library and 
its options. The refine library is distributed and installed with Fun3D by 
default. 


8.1 Geometry Specification and Grid Freezing for re- 
fine 

When adapting a grid with refine, all boundary faces must be specihed as 
frozen or a geometry dehnition mush be provided via FAUXGeom. Use the 
default patch_lumping='none' in the &raw_grid namelist, as lumping will 
change boundary patch indexes making it more difficult to specify geometry. 


8.1.1 No geometry, where the surface nodes are frozen. 

REFINE cannot preserve the high aspect ratio structures within viscous layers, 
and so viscous layers must be frozen for a specihed distance away from the 
surface to maintain grid quality. This is invoked with the adapt_freezebl 
command within the feadaptationunechanics namelist, see section B.4.31 for 
more details. 

Additionally, specihc surfaces that do not have a viscous boundary condi- 
tion can be frozen by listing the surface numbers (one per line) in a hie named 
[pro j ect_rootname] .freeze. For example, [pro j ect_rootname] .freeze that 
contains 

5 

7 


will freeze points on boundary patches 5 and 7. This is also useful for boundary 
surfaces that do not have an analytical dehnition handled by FAUXGeom. 
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8.1.2 FAUXGeom for Planar Boundaries 

For viscous problems, where the mesh on the complex geometry of the body 
is frozen, FAUXGeom can be used to provide an analytical dehnition of the 
farheld boundary surfaces. This allows adaptation to occur on the planar sur- 
faces of the mesh, even when the boundary layer mesh is frozen. This is a 
particularly important capability for symmetry planes. At present, FAUX- 
Geom can only handle planar surfaces. 

FAUXGeom reads the hie faux_input. Here is an example hie: 


4 

5 xplane -5.0 
3 yplane -1.0 
1 zplane 1.0 
16 general_plane 2.0 
0.707 0.707 0.0 

The hrst line is how many faux surfaces are being dehned. The subsequent 
lines have a face number, type of face, and a distance associated with the 
particular geometry. In this example, the hrst faux face dehned corresponds 
to surface 5 in the mesh and is a x = —5.0 constant plane. Faux faces are 
similarly dehned for the z and y planes of surfaces 3 and 1. Surface 16 is 
a plane perpendicular to a (0.707,0.707,0.0) normal that is located 2.0 away 
from the origin in the direction of the normal; the plane passes through the 
point (1.414,1.414,0.0). 

8.2 Performing Feature-Based Adaptation 

The feadapt jnetric.construction variable adapt_f eature_scalar_f orm de- 
hnes the operator that is applied to the adapt_f eature_scalar_key to com- 
pute an adaptation intensity. This intensity is raised to the adapt ^exponent 
power to produce a scaling of an isotropic element size estimate on the cur- 
rent grid. The anisotropy of the metric is introduced by the Hessian of the 
adapt _hessian_key variable. 

Set restart_read=' on' in section B.4.13 to read the how solution. Run 
NODET with the --adapt command line option in the directory with the how 
restart. The result will be a new grid and interpolated solution hie with 
the adapt.project project name. After adaptation, the how solver can now 
be restarted with this new grid and interpolated solution by changing the 
pro j ect_rootname. 

8.3 Performing Adjoint-Based Adaptation 

Adjoint-based adaptation requires that a how solution be calculated in the 
Flow directory and an adjoint solution be calculated in the Adjoint directory. 
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See section 6 for more information on obtaining an adjoint solution. The 
adjoint solution is based on the functional dehned in rubber. data and this is 
the same functional targeted for grid adaptation. 

Adaptation is performed by executing dual with the command line op- 
tions --rad — adapt. The adjoint solver reads the funSd.nml in the ../Flow 
directory), so this is the place to specify feadapt jnetric.construction and 
&adapt_mechanics options. The freeze and FAUXGeom hies are read in the 
current directory, Adjoint. 

The result will be a new grid and interpolated solution restart hie in the 
../Flow directory and an interpolated adjoint restart in the Adjoint directory. 
The project name of these new hies is adapt ^project. 


8.4 Scripting Grid Adaptation 

The Fun 3D installation includes the f 3d script. To hnd the other components 
of the Fun 3D suite, the f3d script expects to be in the bin directory of the 
Fun 3D installation. Don’t copy or link f 3d from the bin directory. The input 
hie case_specif ics is described in section 8.4.1. 

Execute the f 3d script in a directory that contains all of the the input hies 
(e.g., grid, fun3d.nml, case_specif ics). The script will create the required 
Flow and Adjoint directories to run the case. It has the following commands. 


usage: f3d <command> 
<command> description 


start Start adaptation 

view Echo a single snapshot of stdout 

watch Watch the result of view 

shutdown Kill all running fun3d and ruby processes 

clean Remove output and sub directories 

function [name] write rubber. data with cost function [name] 


The command start begins adaptation by launching a background job. The 
commands view and watch allow the adaptation progress to be monitored. 
(Use Ctrl-C to escape the watch command.) The shutdown command kills 
all ruby (f3d) and Fun 3D jobs. The clean command removes the Flow and 
Adjoint subdirectories and the output log hie. The function command with 
argument creates the rubber. data hie to dehne the adjoint cost function. 


8.4.1 Input File case specifics for f3d Script 

The f3d script has one input hie, named case.specif ics. Here is an example 
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root_project ' ' 
number_of _processors 2 
mpirun_conimand ' mpiexec ' 
f irst_iteration 1 
last_iteration 10 

# Any text after a number sign is a comment. 

where the defaults are listed. Adaptation will be performed from the first grid 
adaptation iteration 1 to the last grid adaptation iteration 10. The string in 
quotes next to root_project is the project root name. A two digit iteration 
number will be appended to it. The project name for the first adaptation will 
be [root.project] 01 and the last will be [root_project] 10. All the hies 
required to run NODET and DUAL should be provided in the current directory 
and the grid hlename should include the root project name and iteration num- 
ber, [root_project] 01. Flow and Adjoint subdirectories are created by the 
script during execution, and the input hies are placed in their correct location 
by the script. 

Command line options can be passed to the codes via, 

all_cl ' ' 
flo_cl ' ' 
adj_cl ' ' 
rad_cl ' ' 

where all_cl is provided to all codes, flo_cl is provided to nodet, adj_cl 
is provided to dual during the adjoint solve, and rad_cl is provided to dual 
during error estimation and adaptation. For example, the line 

adj_cl ' — outer_loop_krylov ' 

turns on Krylov projection wrapping to stabilize the adjoint solve. 

The main input hie funSd.nml provided in the cnrrent directory can be 
modihed by the following commands 

all_nl [' variable '] = value 
f lo_nl [' variable '] = value 
adj_nl [' variable '] = value 
rad_nl [' variable '] = value 

where allml changes funSd.nml for all codes, flo_nl for NODET, adj_nl for 
DUAL during the adjoint solve, and rad_nl for DUAL dnring error estimation 
and adaptation. An example is 

adj _nl [ ' steps ' ] =500 

adj _nl [ ' stopping_tolerance ' ] =1 . Oe-12 
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where the termination criteria of the adjoint solver can be specihed separately 
than the flow solver. 

The case_specif ics is actually executable Ruby code. This allows values 
to be computed or conditionally executed, but also require nested quotes for 
character strings, 

rad_nl [ ' adapt_complexity ' ] = 5000*iteration 
number_of _processors 128 if (iteration>5) 
all_nl [ ' f lux_construction ' ] = "'vanleer'" 
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9 Design Optimization 


The Fun3D design framework uses a gradient-based optimization procedure. 
One potential approach to obtaining the required sensitivity derivatives is 
a conventional forward mode of differentiation, such as finite-differencing, 
complex-variable formulations, operator overloading, or direct differentiation. 
Since the cost of these techniques scales directly with the number of input pa- 
rameters, these methods are most efficient for problems where the number of 
outputs is considerably larger than the number of inputs. For such problems, 
Fun3D provides a complex variable formulation as described in section 9.14. 
However, for most aerodynamic design problems, the converse is true; the 
number of design variables is typically much larger than the number of objec- 
tive functions and/or constraints. In this context, an adjoint, or reverse mode 
of differentiation is preferred. 

Fun 3D provides a discrete adjoint capability to efficiently determine the 
sensitivities required by a gradient-based design procedure. The adjoint ap- 
proach enables the user to compute sensitivity derivatives of an output function 
with respect to an unlimited number of design variables at a cost equivalent 
to a single additional flow solution. For a general review of sensitivity analysis 
techniques, see [9] and [10]. 

The adjoint approach used in Fun3D relies on discrete linearizations of the 
relevant components of the flow solver. Most of Fun3D’s compressible perfect 
gas and incompressible capabilities are accounted for within the adjoint-based 
framework. Discretely consistent sensitivities have been demonstrated for both 
steady and unsteady inviscid, laminar, and turbulent flows based on the one- 
equation model of Spalart and Allmaras. Grid topologies may contain any 
combination of element types and may also contain overset grid discretizations. 
Grids may be static, non-inertial, or may contain any combination of static, 
rigidly- moving, or deforming overset component grids. Both compressible and 
incompressible formulations are available. The most commonly-used boundary 
conditions are implemented in the adjoint framework, and a broad range of ob- 
jective/constraint functions is also available. However, the user is encouraged 
to review the latest release notes or contact Fun3D-Support@lists.nasa.gov 
to determine if a specihc analysis capability is currently supported by the ad- 
joint implementation. For a detailed overview of the adjoint-based procedure 
used in Fun3D and examples of its use for design optimization, see [11] and 
the references contained therein. 

Users are encouraged to gain extensive experience using Fun 3D for anal- 
ysis purposes before attempting design optimization. This experience will aid 
in properly setting up optimization cases, understanding the steps involved, 
and interpreting the results. 

The adjoint-based algorithms are very efficient, but a typical optimization 
will still require the equivalent of 0(20) typical analyses. Therefore, secur- 
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ing sufficient computational resources is critical to performing realistic high- 
fidelity design. It should also be noted that the various optimization packages 
supported by Fun 3D may behave very differently for a given design problem; 
moreover, the optimal algorithm is generally problem-dependent. 

At this time, the documentation provided here is aimed at design opti- 
mization of steady flows. The extension to simulations involving unsteady 
flows is available for general use (e.g., see [12]), but is not currently covered 
here. Please contact Fun3D-Support@lists.nasa.gov if interested in using 
this capability. 

9.1 Objective/Constraint Functions 

To perform a gradient-based optimization, the user must specify at least one 
objective function to quantify the merit of the conhguration. In the Fun 3D 
design infrastructure, such objective functions may take a very general form as 
described here. Note that all of the supported optimization packages always 
seek to minimize the chosen objective function. Care should be taken to pose 
the objective function accordingly. Multiple outputs may be accounted for in 
a variety of ways. Constraints may be included implicitly within the objective 
function(s) as penalty terms. Explicit constraint functions may also be posed, 
as either equality or inequality constraints. 

Note that the primary limitation in posing the problem statement is the 
general ability of the chosen optimization package to handle the design prob- 
lem posed by the user. For example, the PORT optimization software does 
not support the use of explicit constraints. KSOPT is the only supported op- 
timization package that supports the use of more than one objective function; 
however, Fun 3D offers several approaches to scalarize multiple objectives for 
other packages. Multi-point design is also supported in several forms. See 
section 9.9 and section 9.10 for specific details on these capabilities. 

The Fun 3D flow and adjoint solvers do not distinguish between objective 
functions and constraints. The solvers themselves merely provide function 
values and their sensitivities for use during the optimization procedure. The 
actual optimization packages are the only components in the design framework 
that make a distinction between objective functions and constraint functions. 

9.1.1 Terminology 

It is useful to establish some basic terminology when composing the design 
problem statement. Within the Fun 3D design infrastructure, the user speci- 
hes one or more component functions based on typical solver outputs. These 
component functions are then combined to form a single composite function. 
Multiple component functions may be used to form composite functions, and in 
turn, multiple composite functions may ultimately be specified. The user then 
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classifies each composite function, designating it either an objective function 
or a constraint function. Again, this distinction is solely for the optimiza- 
tion algorithm; Fun 3D simply evaluates and linearizes each of the composite 
functions in a generic sense and provides them to the optimization scheme. 

The adjoint formulation requires a separate adjoint solution for each com- 
posite function. For example, a drag-minimization problem with an explicit 
lift constraint will generally require two adjoint solutions at each step of the 
design procedure (one based on drag and one based on lift). Rather than per- 
forming separate adjoint executions for each function, Fun3D’s adjoint solver 
is implemented such that multiple adjoint solutions may be computed simulta- 
neously by cycling through a series of right-hand side vectors. In this manner, 
much of the computational overhead associated with discretizing the adjoint 
system is amortized over the collection of specihed functions, and each addi- 
tional function only increases the overall computational cost by approximately 
40%. See [7] for further details on this aspect of the implementation. 

9.1.2 Functional Form 

Composite functions take the following general form in Fun3D: 


Here, the index corresponds to the number of individual component func- 
tions comprising composite function i. The factor ujj represents a user-specihed 
weighting coefficient in the summation; Cj is a Fun 3D scalar output quantity, 
C* is a user-specihed target value for that output quantity, and pj is a user- 
specihed exponent. The currently available Fun 3D output functions that may 
be posed as Cj are listed in Table 10. Though not explicitly represented in 
Eq. 1, the implementation also allows the user to only use specihc boundary 
contributions to Cj and not all boundaries if desired. This could be used to 
focus the optimization function on forces acting on the wing or tail only. Note 
that when composing an objective or constraint function it is often helpful 
to scale the expected value to an 0{1) quantity. This can be readily done 
using the ujj factor. Additional details relevant to more complex functions are 
covered in section 9.2. The specihc input mechanism for providing each of 
the component/composite function parameters will be discussed at length in 
section 9.6.2. 

To demonstrate the use of the general functional form given by Eq. 1, 
several examples are given here: 

Unconstrained Drag Minimization For an unconstrained problem in 
which the user wishes solely to minimize drag, one potential approach might 



( 1 ) 
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Table 10: 

Keyword 

Objective/constraint component function keywords. 
Function 

cl, cd 

Lift, drag coefficients 

clp, cdp 

Lift, drag coefficients: pressure contributions 

civ, cdv 

Lift, drag coefficients: shear contributions 

cmx, cmy, cmz 

x/y/z-axis moment coefficients 

cmxp, cmyp, cmzp 

x/y/z-axis moment coefficients: pressure contributions 

cmxv, cmyv, cmzv 

x/y/z-axis moment coefficients: shear contributions 

cx, cy, cz 

x/y/z-axis force coefficients 

exp, cyp, czp 

x/y/z-axis force coefficients: pressure contributions 

cxv, cyv, czv 

x/y/z-axis force coefficients: shear contributions 

powerx, powery, powerz x/y/z-axis power coefficients 

eled 

Lift-to-drag ratio 

f om 

Rotorcraft figure of merit 

propeff 

Rotorcraft propulsive efficiency 

rtr_thrust 

Rotorcraft thrust function 

pstag 

RMS of stagnation pressure in cutting plane disk 

boom_targ 

Near-field p/poo pressure target 

sboom 

Coupled sBOOM ground-based noise metrics 

ae 

Supersonic equivalent area target distribution 

press_box 

RMS of pressure in user-defined box, also pointwise dp/dt, dp/dt 

cpstar 

Target pressure distributions 


be to specify a single composite function consisting of a single component 
function with uji = 1.0, C\ = cd, = 0.0, and p\ = 2. In this manner, the 
objective function is simply 


/ 



( 2 ) 


where the quadratic form has been chosen to provide a convex function space. 


Drag Minimization with Lift Penalty To add an interior penalty term 
accounting for a lift equality constraint of 0.5, one might instead use two 
component functions within the same single composite function where uji = 
10.0, U 2 = 1.0, Cl = cd, C 2 = cl, C{ = 0.0, C 2 = 0.5, and pi = P 2 = 2. These 
parameters yield 

/ = lOCi, + (Cl - 0.5)2. (3) 

In this case, any deviation of the lift coefficient from its target value of 0.5 
will “penalize” the objective function. The weighting parameters uij have been 
selected based on typical magnitudes of Cd and Cl, so as to produce roughly 
equivalent contributions to the objective function. Note that the choice of 
these weighting parameters is heuristic in nature and often troublesome in 
practice. 
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Drag Minimization with Explicit Lift Constraint In this example, the 
lift constraint Cl = 0.5 is instead posed as an explicit constraint for the opti- 
mizer. Here, two composite functions are formed, each with a single component 
function. First, an objective function is specihed as in Eq. 2 with uji = 1.0, 
Cl = cd. Cl = 0.0, and pi = 2. As before, this yields 

/i = Cl (4) 

However, an additional composite function for the lift constraint is also spec- 
ihed with uji = 1.0, Cl = cl. Cl = 0.5, and pi = 1, which gives 


/2 = Cl. (5) 

This explicit form of the lift constraint is generally preferred in practice. 

9.2 Some Details on Specific Objective/Constraint 
Functions 

Many of the scalar functions shown in Table 10 and designed to be used as the 
term Cj in Eq. 1 are straightforward. For example, the keyword cd is sufficient 
to characterize a drag-based component function. However, some of the scalar 
functions listed in Table 10 require the user to be aware of specihc requirements 
and/or to provide additional auxiliary data. In this section, scalar functions 
requiring further data and/or explanation are covered. 

9.2.1 Lift-to-Drag Ratio (Keyword: clcd) 

This function must be specihed with a 0 for its boundary index, i.e., it must be 
applied to the entire conhguration and is not available for individual boundary 
patches. It is dehned as 

/=//■ ( 6 ) 

Cd 

9.2.2 Rotorcraft Figure of Merit (Keyword: f om) 

This function is dehned as 


/ 


Cl 


(7) 


Note that this functional form assumes that the rotor axis of rotation is in 
the +z direction. The dehnition also represents the square of the traditional 
Figure of Merit function. See [13] for a motivation for this modihed form. 
This function must be specihed with a 0 for its boundary index, i.e., it must be 
applied to the entire conhguration and is not available for individual boundary 
patches. 
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9.2.3 Rotorcraft Propulsive Efficiency (Keyword: propeff) 

This function is defined as 


/ 


-a 

Cm: 


( 8 ) 


Note that this functional form assumes that the rotor axis of rotation is in 
the +z direction. The minus sign has been introduced to yield a positive 
efficiency since Cm^ is negative. This function must be specified with a 0 for 
its boundary index, i.e., it must be applied to the entire configuration and is 
not available for individual boundary patches. 


9.2.4 Rotorcraft Thrust (Keyword: rtr thrust) 

This function is defined as the force normal to the plane of a rotor system: 

f = Cl cos(6»t) - Cd sin(6»T) (9) 

where the angle from +z-direction 9^ in radians is the variable thrust_angle 
that must be set in the source file LibF90/custom_transf orms.f 90. 


9.2.5 RMS of Stagnation Pressure (Keyword: pstag) 

This function computes the RMS of stagnation (total) pressure in a circu- 
lar disk that passes through the grid in a specified location and orientation. 
This is commonly employed to quantify engine inlet distortion. The user must 
specify the variables in the &pstag_function namelist within funSd.nml. See 
section B.4.37 for details related to this namelist. This function is only avail- 
able for compressible flows. 

9.2.6 Near-field p/poo Pressure Target (Keyword: boom_targ) 

This function allows inverse design of near-field pressure signatures, which is a 
commonly used tactic for creating low sonic boom configurations. This func- 
tion is only available for compressible flows. The user specifies yz-coordinate 
pairs through which rays are passed parallel to the x-axis. Off-body pressure 
distributions in the vicinity of an aircraft are nominally oriented parallel to 
the freestream velocity vector. In the case of a nonzero angle of attack, the 
rays are rotated about a user-specified center of rotation to align them with 
the freestream direction. The user also provides the minimum and maximum 
x-extent for the rays. A user-specified number of points are evenly distributed 
along each ray and the grid element containing each point is identified. See 
section B.4.33 for guidance on the required namelist inputs. 

The functional form is given by 
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( 10 ) 


where p is the local static pressure. The summation takes place over all points 

in the rays defined by the user, and the values of p are evaluated at the 

* 

centroids of the enclosing elements. The values of a;, and ^ are user-supplied 


pointwise weighting coefficients and target values of p/poo, respectively, which 
must be provided in a file named pressure_target.dat. If this file is not 
present, the target values of p/poo are set to 1.0 and the weighting coefficients 
are set to 1.0. Note that with the above functional form, the target and 
exponent parameters present in Eq. 1 are usually set to 0.0 and 1, respectively. 

A template for pressure_target.dat is typically generated by first ex- 
tracting a set of p/poo distributions for a known configuration by running the 
optimization driver with Operation to perform set to 1 (“Analysis only”) 
in ammo. input. Note that the input value weight must be set to .true, 
and the desired ray extraction {y, z) coordinate pairs must be specified in the 
&sonic_boom namelist in funSd.nml. This operation produces a file named 
pressure_signatures.dat, which uses the same file format intended for the 
pressure_target.dat target input file. (Note that the file format is amenable 
to Tecplot™ usage.) The user may then use the pressure_signatures.dat 
file to develop a pressure_target.dat input file by modifying the existing 
pressures to reflect their target values as desired. Note that by specifying 
weight=.true . in the &sonic_boom namelist, a column of data representing 
pointwise weighting coefficients (all initially set to 1.0) will be provided in 
pressure_signatures.dat. This column of data is required to be present in 
pressure_target.dat. The individual weights may be left as 1.0, or they 
may be modified on an individual basis to optionally weight a specific region 
of the signature more or less in the final objective function. A brief example 
of this file format for a case involving two off-body signatures is shown below. 
Note that target distributions need not have the same number of locations as, 
nor line up with, the eventual sampling locations along the extraction rays. 
Fun3D will linearly interpolate between input target values to obtain values 
at the sampling locations. 


VARIABLES = "x" , "y" , "z", "p/pinf", "weight" 
zone t="Signal 1" 

-0.500E+01 O.lOOE-11 0.826E+00 O.llOOlOE+01 O.lOOE+01 
-0.472E+01 O.lOOE-11 0.835E+00 O.llOOllE+01 O.lOOE+01 
-0.415E+01 O.lOOE-11 0.855E+00 0.110012E+01 O.lOOE+01 
-0.354E+01 O.lOOE-11 0.876E+00 0.110016E+01 O.lOOE+01 
zone t="Signal 2" 

-0.500E+01 O.lOOE-11 0.182E+01 0.102008E+01 O.lOOE+01 
-0.472E+01 O.lOOE-11 0.183E+01 0.102008E+01 O.lOOE+01 
-0.414E+01 O.lOOE-11 0.185E+01 0.102009E+01 O.lOOE+01 
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-0.356E+01 O.lOOE-11 0.187E+01 0.102012E+01 O.lOOE+01 
-0.335E+01 O.lOOE-11 0.188E+01 0.105013E+01 O.lOOE+01 
-0.320E+01 O.lOOE-11 0.188E+01 0.105014E+01 O.lOOE+01 
-0.264E+01 O.lOOE-11 0.190E+01 0.105017E+01 O.lOOE+01 

9.2.7 Coupled sBOOM Ground-Based Signatures, Noise Metrics, 
and Equivalent Areas (Keyword: sboom) 

This option uses the adjoint capability of the Burgers equation boom prop- 
agation code sBOOM [14] to inversely design ground pressure signatures, 
optimize a ground-based noise metric, or match equivalent area distributions. 
[15-17] Fun3D must be conhgured and built with the sBOOM library as 
described in section A. 7. 13 to use this capability. 

In the coupled Fun3D-sBOOM implementation, Fun3D is responsible 
for computing pressure signals in the immediate vicinity of an aircraft (typi- 
cally within 10 body lengths). The sBOOM tool then propagates these dis- 
turbances to the ground using an augmented Burgers equation that considers 
effects such as non-linearity, thermo-viscous absorption, and any number of 
molecular relaxation phenomena during the propagation of waveforms through 
the atmosphere. In this manner, the user can directly simulate ground-based 
noise metrics such as A-weighted loudness or compute other loudness measures 
(e.g.. Perceived Level) from the computed ground signatures. In a similar fash- 
ion, a coupled adjoint problem is used to determine the discrete sensitivities 
of the ground-based metrics with respect to any of Fun3D’s typical design 
parameters which may then be used to optimize the configuration. 

sBOOM can generate off-track signatures based on ray theory using user 
input azimuthal angles. sBOOM can also predict the sonic boom signatures 
in the presence of wind, turn rate (changing heading angle), climb rate, climb 
angle, and acceleration (dMach/dt). During maneuvering flight, boom focus- 
ing is possible. The current version sBOOM in not able model focusing and 
will exit with an appropriate message if focusing occurs. 

Equivalent area distributions are computed with reversed augmented Burg- 
ers equation (when rs< (alt— hg)) or a direct conversion of off-body pressures 
(when rs> (alt— hg)). This is different than the Mach cut equivalent area 
matching approach in section 9.2.8. The discrete sensitivities of the difference 
between a target and the computed equivalent areas are provided to Fun3D. 
The target area is specified with the target.dpress and target_xx variables 
in the fesboom namelist. 

The user must provide inputs relevant to the nearheld pressure signal ex- 
traction (see section B.4.33) as well as parameters specihc to the sBOOM 
library (see section B.4.34). Note that when the sboom keyword is used as 
the component function name, the actual form of the objective/constraint 
component function is determined entirely within sBOOM. In this case, the 
values of a;, C* , and p in Eq. 1 are ignored. This function is only available for 
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compressible flows. 


9.2.8 Supersonic Mach Cut Equivalent Area Distribution 
(Keyword: ae) 

This function aims to match a target Mach cut equivalent area distribution for 
supersonic flows. The Mach cut equivalent area distribution is directly com- 
puted from surface pressures and geometry for this function. This is a different 
approach than the equivalent area computation of sBOOM in section 9.2.7. 
The function is defined as 


where N represents the total number of longitudinal stations used to sample 
the solution and geometry for the current azimuth, and Lj and Vi are the lift 
and volume contributions, respectively, to the current equivalent area. The 
term A* represents the user-supplied target equivalent area distribution. The 
u>i enables the user to locally weight individual segments of the distribution 
if desired. Note that with the above functional form, the target and expo- 
nent parameters present in Eq. 1 are usually set to 0.0 and 1, respectively. 
This function is only available for compressible flows, and the conhguration is 
assumed to align with the x-axis. 

Any number of desired azimuthal (centerline/off-track) locations may be 
specified and used as individual component functions. The user must pro- 
vide the data indicated in the &equivalent_area namelist in funSd.nml as 
described in section B.4.35. A centerline symmetry plane may be used to 
reduce computational expense; in this case, the cutting planes at each longitu- 
dinal station will be correctly accounted for on the virtual side of the aircraft. 
A hie ae_target.dat must also be provided, which describes the (optionally 
weighted) target equivalent area prohles. 

A template for ae_target.dat is typically generated by hrst extracting a 
set of equivalent area distributions for a known conhguration by running the 
optimization driver with Operation to perform set to 1 (“Analysis only”) in 
ammo. input. This operation will produce a Tecplot™ hie [project_rootname] 
_ae.dat which uses the same hie format intended for the target input hie 
ae_target.dat. The user may then use the [pro j ect_rootname] _ae.dat hie to 
develop a ae_target.dat input hie by modifying the existing equivalent areas 
to rehect their target values as desired. Note that the hie [project_rootname] 
_ae.dat contains a column of data representing the pointwise weighting coeffi- 
cients uji (all initially set to 1.0). This column of data is required to be present 
in ae_target.dat. The individual weights may be left as 1.0, or they may be 
modihed on an individual basis to optionally weight a specihc region of the 
distributions more or less in the hnal objective function. A brief example of 


N 



( 11 ) 
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this file format for a case involving three azimuthal signatures is shown below. 
Note that target distributions need not have the same number of locations as, 
nor line up with, the longitudinal sampling locations. Fun3D will linearly 
interpolate between input target values to obtain values at the sampling lo- 
cations. Also note that in the input hie ae_target.dat, the second and third 
columns of the format are ignored. 


VARIABLES = "x" , "V", "L" , "Ae", "weight" 
zone t="Ae Function 1" 


-O.OlOOOE+00 

0.13839E+01 

0.27678E+01 

0.41517E+01 


O.OOOOOE+00 

0.25482E-01 

0.47548E-01 

0.76165E-01 


O.OOOOOE+00 

-0.26289E-02 

-0.64155E-02 

-0.10361E-01 


O.OOOOOE+00 

0.22853E-01 

0.41133E-01 

0.65804E-01 


zone t="Ae Function 2" 


O.lOOOOE+01 

O.lOOOOE+01 

O.lOOOOE+01 

O.lOOOOE+01 


-O.OlOOOE+00 

0.14018E+01 

0.28036E+01 

0.42054E+01 

0.56072E+01 

0.98126E+01 


O.OOOOOE+00 

0.25700E-01 

0.48215E-01 

0.77379E-01 

0.11457E+00 

0.30728E+00 


O.OOOOOE+00 

-0.26610E-02 

-0.64628E-02 

-0.10358E-01 

-0.14045E-01 

-0.25726E-01 


zone t="Ae Function 3" 


-O.OlOOOE+00 
0. 14155E+01 
0.28310E+01 
0.42465E+01 


O.OOOOOE+00 

0.26009E-01 

0.48902E-01 

0.78591E-01 


O.OOOOOE+00 

-0.26166E-02 

-0.62883E-02 

-O.lOOllE-01 


O.OOOOOE+00 

0.23039E-01 

0.41752E-01 

0.67020E-01 

0.10052E+00 

0.28156E+00 

O.OOOOOE+00 

0.23392E-01 

0.42614E-01 

0.68579E-01 


O.lOOOOE+01 

O.lOOOOE+01 

O.lOOOOE+01 

O.lOOOOE+01 

O.lOOOOE+01 

O.lOOOOE+01 

O.lOOOOE+01 

O.lOOOOE+01 

O.lOOOOE+01 

O.lOOOOE+01 


Finally, the solver will also provide the user with a Tecplot™ output hie 
[pro j ect_rootname] _ae_cuts_i.dat for the ith specihed equivalent area func- 
tion. These hies contain the actual cross-sectional slices of the aircraft that 
were generated for each azimuthal function. 


9.2.9 RMS of Pressure in User-Defined Box, Pointwise dp/dt, 
dp/dt (Keyword: press box) 

This function computes the RMS of a quantity in Cartesian region, which is 
typically used to indicate a region of the how is important for grid adaptation 
or that huctuations in a region should be minimized in a design. These func- 
tions rely on the inputs associated with the &press_box_function namelist; 
see section B.4.36 for details. The function may be composed of the RMS 
value of the pressure within a user-dehned box in the domain, or for unsteady 
simulations, the time derivative of pressure or density (for compressible hows) 
at a single grid point. 


9.2.10 Target Pressure Distributions (Keyword: cpstar) 

Fun 3D has an inverse design capability where the objective function may 
be composed of target pressure distributions. The hie containing the jth 
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target distribution must be named cpstar.data.j. However, setup is te- 
dious, primarily due to the difficulty in specifying pressure distributions on 
a three-dimensional conhguration. If this capability is of interest, please con- 
tact Fun3D-Support@lists.nasa.gov for more detailed guidance. 

9.3 Geometry Parameterizations 

In order to perform shape optimization, Fun3D must be provided with a 
set of design variables describing the geometric shape of the conhguration. 
Fun3D is currently set up to interface directly with geometry parameteriza- 
tions provided by MASSOUD [18], Bandaids [19], or Sculptor™. MASSOUD 
and Bandaids are software packages developed by Jamshid Samareh of NASA 
Langley (Jamshid.A.Samareh@nasa.gov). Users should contact him for copies 
of the software; tutorial information for these tools is available on the Fun3D 
website. These packages allow the user to parameterize completely arbitrary 
shapes using a free-form deformation technique. The packages are very ef- 
hcient, robust, and also provide analytic Jacobians of the parameterization, 
which are necessary for FuN3D-based design. Sculptor™ is a popular commer- 
cial package developed by Optimal Solutions and also provides the necessary 
data for FuN3D-based design. Note that any combination of parameteriza- 
tions based on these tools may be used within the context of a single optimiza- 
tion. For example, the planform of a wing or tail surface may be best treated 
using MASSOUD, while Bandaids or Sculptor™ may be most appropriate for 
a wing-body hllet region or a feature such as a fuselage protuberance. Finally, 
the user may also use a parameterization scheme of their choosing; see section 
section 9.3.4 for further details. 

9.3.1 Surface Grid Extraction 

To parameterize a surface grid using any of the above tools, it must hrst be 
extracted to a Tecplot™ hie. To do this, add a &massoud_output namelist 
to funSd.nml to group all of the required boundary patches for a body to be 
parameterized into a single body (see also section B.4.32): 

&mas s oud_ out put 
n_bodies = 2 
nbndry(l) = 6 
boundary_list(D = '3-8' 
nbndry(2) = 3 

boundary_list (2) = '9,10,12' 

/ 

Note that the boundary indices shown here must rehect any patch lump- 
ing that may have been requested in the &raw_grid namelist (see also sec- 
tion B.4.2). A single iteration of the how solver should now be executed 


paremieterize 2 bodies: wing and tail 

# of bounds that comprise wing 
wing bounds (account for lumping!) 

# of bounds that comprise tail 
tail bounds (account for lumping!) 


62 


with the --write_massoud_f ile command line option. This will generate a 
[pro j ect_rootname] _massoud_bndry#.dat file for each of the boundary groups 
present in the &massoud_output namelist. These files contain the information 
necessary to parameterize the surface grid using any of the aforementioned 
tools. See the documentation for those packages for further instructions on 
how to construct the actual parameterization. 

9.3.2 Access to Executables 

If MASSOUD, Sculptor™, or a user-dehned executable is being used for param- 
eterizations, the executable for those packages must be available in the runtime 
PATH. The executables for MASSOUD and Sculptor™ must be named massoud 
and sculptor, respectively. If using a user-dehned parameterization package 
(see section 9.3.4), the executable must be named according to the input pro- 
vided in ammo. input (see section 9.5.1). The optimization driver supplied with 
Fun3D will attempt to call these executables if such parameterization types 
are present. If Bandaids are being used, no additional executables must be 
supplied; all Bandaid evaluations are handled internally by Fun3D. 

9.3.3 Notes on Using Sculptor™ 

If Sculptor™ is being used, Fun3D will invoke Sculptor™ in batch (non-GUI) 
mode during the course of the optimization. However, current versions of 
Sculptor™ will still attempt to communicate with an X server, even when run 
in this fashion. If the system does not run an X server (such as compute nodes 
on a cluster), then a fake X server such as Xvfb is recommended. You will 
need to execute the fake server prior to running the design optimization. For 
example, a run script may have the following commands: 

Xvfb :1 & 

export DISPLAY=:1.0 # for bash 

setenv DISPLAY :1.0 # for c shell 

[any command that uses Sculptor] 

The syntax here may vary; if this does not allow the optimization driver to 
run Sculptor™ in batch mode successfully on the system, the user should get 
in touch with Sculptor™ support for assistance. 

In addition, the parameterization of all bodies treated using Sculptor™ 
must be bookkept within a single set of Sculptor™ input files. For example, 
in the wing-tail example above, both bodies must be contained in a single in- 
stance of Sculptor™ hies. Therefore, the &massoud_output namelist described 
above should group all of the desired boundaries necessary to describe the 
geometry(s) of interest into a single body: 
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&massoud_output 
n_bodies = 1 
nbndry(l) = 9 


wing and tail grouped into a body 
# of tail and wing bounds 
wing and tail boundaries 


boundary_list (1) = '3-10,12 


/ 


Each of the desired bodies may be worked on independently within Sculp- 
tor, but they must ultimately appear as a single body to Fun3D. 

9.3.4 Using Other Parameterization Packages 

Fun3D provides a generic interface for user-dehned external geometric pa- 
rameterization packages. The user-dehned tool must provide the surface mesh 
coordinates as a function of some vector of design variables for the body of 
interest. The partial derivatives of these coordinates with respect to the design 
variables must also be supplied. See [20] for an example of such an approach. 

To invoke a user-dehned parameterization package for one or more bodies 
present in the simulation, the user must tag individual bodies appropriately 
(see section 9.6.2) and provide the executable name to be invoked by Fun3D’s 
design driver at run-time via the input deck ammo. input (see section 9.5.1). 
This may be a binary executable or simply a script that invokes other user- 
dehned operations that may be necessary to evaluate the parameterization and 
its sensitivities. 

When Fun 3D requires an evaluation of the user-dehned parameterization 
for a body (or its sensitivities), it will hrst write a hie named customDV.i, where 
the i suffix corresponds to the body index for which Fun 3D is requesting 
updated surface data. The format of the customDV.i hie is as shown below. 

#User defined design variables 
#Number of DVs 


1 . 907460000000000E+00 
0 . OOOOOOOOOOOOOOOE+00 
-0 . 002469800000000E+00 

The hrst two lines are comment lines, and the third specihes the total number 
of design variables in the parameterization for the current body (whether the 
user may have designated some active and others inactive in rubber. data; see 
section 9.6.2). The remaining lines in the hie contain the current value of each 
design variable, with one value per line. 

After writing the customDV.i hie, Fun 3D will then invoke the user-specihed 
executable command provided in ammo, input. Fun 3D will append a space and 
a single integer to this executable command, where the integer corresponds to 
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the body index for which Fun 3D requires an evaluation of the parameteriza- 
tion. The user-provided executable (or script) must be capable of parsing this 
integer command-line option in order to process the requested body. 

After the external package has completed the evaluation of the parameteri- 
zation and its sensitivities, the data must be supplied to Fun 3D via a Tecplot™ 
hie named model. tec. i.sdl, where the integer i in the hlename represents the 
current body index. The format of this hie must be as follows: 

TITLE = "PARAMETERIZATION DATA" 

VARIABLES = "X" "Y" "Z" "ID" "XDl" "YDl" "ZDl" "XD2" "YD2" "ZD2" "XD3" "YDS" "ZDS" 

ZONE T = groupO, I = 4, J = 1, F=FEP0INT 

0.0 1.0 0.0 235 1.234 -23.0 892.1 -23.0 82.123 -90.2 -905.2 857.12 348.2 
1.0 1.0 0.0 872 4.14 -0.123 -0.324 23.13 2978.2 -0.114 -982.4 -3.22 0.1185 
1.0 0.0 0.0 912 -0.34 0.938 8.45 78.23 -35.2 -0.023 8.32 -0.009 -0.92 
0.0 0.0 0.0 455 9.01 -8.23 -0.456 2.56 1.21 0.0 -0.091 -1.22 0.0088 
12 3 4 

The trivial (and completely contrived) example shown here provides sur- 
face mesh point locations and the corresponding sensitivities for a single quad 
element parameterized by three design variables. The title in the hrst line may 
contain anything the user desires. The variables identihed in line 2 represent 
the X-, y-, and z-coordinates for the current surface mesh point, the node in- 
dex in the global grid for the current surface mesh point, and the sensitivity 
derivatives of the x-, y-, and z-coordinates of the current surface mesh point 
with respect to each of the design variables provided by Fun 3D in customDV.i 
above. The hie should contain a single zone, indicated by the third line of the 
example hie shown. Here, the zone title specihed by T = may be anything the 
user desires. The I = value corresponds to the number of surface mesh points 
for the current body, while the J = value specihes the number of surface ele- 
ments (triangles or quads) contained in the surface mesh for the current body. 
Fun 3D will only read the I = value; the surface mesh topology is immaterial 
in this context. 

In this example, the boating point values have been truncated for read- 
ability; users are strongly encouraged to provide double-precision values in 
practice. The connectivity information at the end of the hie is not used by 
Fun 3D. It may be omitted if desired; however, it is often instructive to load 
this hie into Tecplot™ for visualization. In that context, the connectivity data 
(including the appropriate J = value in the hie header) will be required. 

For very large surface meshes and/or parameterizations containing a very 
large number of design variables, I/O of this ASCII format can be inefficient. 
There is an alternative C-binary /Fortran stream format that may be used in its 
place; interested users should get in touch with Fun3D-Support@lists.nasa.gov 
for further details on this option. 

To support execution of the user-dehned parameterization tool, auxiliary 
hies may be provided in the description.! directory; the hlenames should 
be provided in the hie user.def _param_f iles.data (see section 9.6.1). 
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9.4 Design Optimization Directory Structure 

The optimization driver opt_driver requires a very specific directory struc- 
ture. It can be established by running opt.driver in an interactive mode 
with the — setup .design command line option. The number of design points 
should be 1 for single-point design or greater than 1 for multi-point design. 

opt_driver — setup_design [number of design points] 

This interactive command will prompt the user for several directory paths 
required by the optimization, namely the paths to the Fun 3D source code, 
the configuration directory where Fun 3D was configured and built, and the 
path to the location where the design will be performed. Here, directories 
should be provided as absolute paths contained in single quotes, with trailing 
slashes omitted, i.e., 

' /absolute/path ' 

At the completion of this setup procedure, a summary of the files required 
from the user will be echoed to the screen. The directories created in the 
specified run location are shown in Table 11. The i suffix in description.! 


Table 11: Directory structure required for FuN3D-based design. 

Directory Description 

ammo Location where optimization will be executed 

description.! Location of all baseline input files describing design point i 

model.! Location where analysis &l sensitivity analysis of design point i will be performed 

and model.! represents the design point index. For single-point design, this 
will be 1; for multi-point design, this value will range from 1 to the number 
of user-specified design points. The setup procedure will populate the various 
directories with links to the required Fun 3D executables and templates for 
various input files described below. 

9.5 Contents of the ammo Directory 

The ammo directory will contain files related to the optimization procedure 
itself. This includes the ammo, input input file and a link to the opt .driver 
executable. 

9.5.1 ammo, input 

The input parameters contained in this file control the actual optimization 
procedure. A template of the file will be installed during the setup procedure; 
an example is also provided below. 
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Optimization package 

4 

Base directory from which to run optimization 
' /home/user/TestAMMO ' 

Number of design points 
2 

Weights for each design point 
1.0 
1.5 

Operation to perform 
1 

Restart the optimization 
0 

Maximum number of flow solves 
10 

Maximum number of design cycles 

5 

Relative convergence criterion for subproblem 
l.e-5 

Absolute feasibility tolerance for constraint violation 

110.0 

Number of bodies with spatial transforms 
2 

List of bodies with spatial transforms 
2 3 

Body grouping desired 
0 

Executable for running MPl programs 
'mpirun' 

Number of processors from which to run adjoint solver 
1024 

DOT method 
0 

User-defined parameterization executable name 
' MyParameterizationExecutable ' 

The various inputs specified in the ammo. input input file are described be- 
low. Care should be taken to preserve the structure of this file when modifying 
its contents. 

Optimization package This scalar integer specifies the optimizer to be 
used. The available choices are (1) DOT/BIGDOT™, (3) KSOPT, (4) PORT, 
(5) NPSOL™, and (6) SNOPT™. Note that the PORT package does not sup- 
port the use of explicit constraints. Also note that Fun3D must be configured 
and built against the selected library. 

Base directory from which to run optimization This should be an 
absolute path to the design location specified during the setup procedure. 
Path should be enclosed in single quotes and contain no trailing slashes. 
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Number of design points This scalar integer is the number of design points 
to be considered during the optimization. The value should be at least 1 and 
less than or equal to the number of design points specihed during the setup 
procedure. 

Weights for each design point A non-negative real-valued scalar should 
be specihed on separate lines for each design point. The value represents the 
weighting to be applied in the linear combination of objective functions from 
each individual design point as used to construct the hnal composite objective 
function (see section 9.10). For single point optimization, a single value of 1.0 
should be specihed. 

Operation to perform This scalar integer specihes what operation the 
optimization driver should perform. The valid values are (1) Analysis only, 
(2) Analysis and sensitivity analysis, and (3) Optimization. 

Restart the optimization This scalar integer specihes whether to start the 
optimization from the baseline problem description (0), or to restart the opti- 
mization from a previous optimization run already executed in this directory 
( 1 ). 

Maximum number of flow solves This scalar integer is only relevant for 
PORT-based optimizations and sets an upper limit on the number of flow 
solutions allowed during the design. 

Maximum number of design cycles This scalar integer sets an upper 
limit on the number of design cycles the optimizer may perform. 

Relative convergence criterion for snbproblem This scalar real value is 
only relevant for DOT /BIGDOT™- and PORT-based optimizations and spec- 
ifles the relative function convergence criterion for which the optimization will 
terminate. 

Absolute feasibility tolerance for constraint violation This scalar real 
value is only relevant for optimizations based on the DOT /BIGDOT™, NPSOL™, 
and SNOPT™ packages. The value specihes the feasibility tolerance for con- 
straints. 

Number of bodies with spatial transforms This scalar integer specihes 
the number of MASSOUD-parameterized bodies for which spatial transforms 
should be applied. See also section 9.6.10. 


List of bodies with spatial transforms This is a list of integers sep- 
arated by spaces specifying the MASSOUD-parameterized bodies to which 
spatial transforms are to be applied. There should be Number of bodies 
with spatial transforms entries in this list. If Number of bodies with 
spatial transforms is zero, this line of data should not be present. See also 
section 9.6.10. 

Body grouping desired This scalar integer specihes whether any body 
grouping should be applied. A value of 0 indicates no grouping should be ap- 
plied; a value of 1 indicates grouping should be applied. See also section 9.6.4. 

Executable for running MPI programs This single character string en- 
closed in single quotes will be used as a prehx when running MPI programs. 

This is usually mpirun or mpiexec, depending on the MPI implementation, or 
perhaps aprun on Cray® systems. 

Number of processors from which to run adjoint solver This scalar 
integer specihes the number of processors on which to execute the adjoint 
solver. Normally this is the same number of processors requested for the job 
and used for the how solver. However, in the event of a split communicator 
in the how solver (for Suggar-b-f, Visit, dedicated hie I/O, etc), the adjoint 
solver must be run on the same number of processors that the actual how 
solver was run on (does not include processors set aside for split communicator 
functionalities). 

DOT method This scalar integer is only used for DOT/BIGDOT™-based 
optimization and specihes the optimization method to be used with DOT /BIGDOT™. 
See the DOT /BIGDOT™ documentation for further information. 

User-defined parameterization executable name This string should be 
enclosed in single quotes and represents the name of the executable (or script) 
to be launched if user-dehned geometric parameterizations are to be used. The 
executable should be available in the users PATH. See also section 9.3.4. 

9.6 Contents of the description.! Directory 

The description.! directory serves as a repository for the baseline hies for 
the GFD model, the geometric parameterization, and several other input hies 
related to the computational model for the ith design point. These hies must 
be set up by the user prior to the run and will not be modihed by Fun 3D dur- 
ing execution. During the initial setup procedure, templates for several input 
hies will be placed in this location to aid in setting up the case. During the 
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actual optimization, the optimization driver will copy files from this directory 
into the model . i directory as needed. 

Any hies normally required by the how solver must be present in this 
directory. This would typically include the grid and boundary condition hies 
and funSd.nml. If the mesh uses overset grids assembled with the Suggar++ 
utility, the Suggar++ DCI hie must be present as well. The optional hie 
remove_boundaries_from_f orce_totals (section B.3) may also be present, if 
desired. 

In addition to the hies normally required by the how solver, a number of 
other hies must also be present to perform the design optimization, some of 
which are optional. These are described below. 

9.6.1 Geometry Parameterization Files 

If performing shape optimization, the user must provide the relevant parame- 
terization hies for each body in the mesh to be modihed. The specihc set of 
hies required for each body depends on the parameterization package (s) being 
used. 


MASSOUD Parameterizations For MASSOUD parameterizations, the 
MASSOUD parameterization hies should be named design. gp.j, where j is 
the index of the body to be designed. The hies specifying the values of the 
raw MASSOUD variables should be named design, j for each of the bodies 
to be designed. For FuN3D-based design, the custom design variable linking 
feature of MASSOUD must be used. If the raw MASSOUD variables are 
intended to be used as-is, simply set the linking matrix as the identity matrix 
in the MASSOUD .usd hie. These hies specifying the design variable linking 
for each body should be named design.usd. j . 

The MASSOUD control hie specihes the names of the hies outlined above 
for MASSOUD and must be provided as massoud.j for the jth body. The 
hies listed in the MASSOUD control hie must rehect these names. The hrst 
line of the MASSOUD control hle(s) must have a positive integer equal to 
the number of custom design variables. If the intent is simply to use the raw 
MASSOUD variables as-is, this value is simply the number of raw MASSOUD 
variables for that body. For the in/out-of-core parameter, use in-core (0). 
The hie name for Tecplot™ output viewing must be named model. tec. j for 
the jth body. The design variable grouping hie specihed should be named 
designVariableGroups. j for the jth body. The FAST output hie name can be 
named anything the user wishes; the Fun3D tools do not use this MASSOUD 
output hie. Finally, the user design variable hie for the jth body should be 
named customDV.j. In summary, a massoud.j control hie for the jth body 
should look like the following: 


70 


#MASSOUD INPUT FILE 

# runOption 0-anaIysis, >0-sd users dvs, -1-sd massouds dvs 
52 

# core 0-incore solution, 1-out of core solution 
0 

# input parameterized file 
design. gp. 1 

# design variable input file 
design. 1 

# input sensitivity file - used for runOption > 0 
design. usd. 1 

# output file grid file 
newf rame .fast . 1 

# output Tecplot file for viewing 
model. tec. 1 

# file containing the design variables group 
designVariableGroups . 1 

# user design variable file 
customDV . 1 

Bandaid Parameterizations For Bandaid parameterizations, the input 
files created by the Bandaid setup tool should be named bandaid.data. j for 
the jth body. Because Bandaid parameters behave linearly, the sensitivities 
contained in these hies are constant and this input is all that is required during 
the course of a design. 

Sculptor™ Parameterizations For Sculptor™ parameterizations, the user 

must provide [project_rootname] .mdf , [project_rootname] .sdl, [project_rootname] 

.vol, and [project_rootname] .stu hies. See the Sculptor™ documentation 

for more details on each of these hies. A hie named [project_rootname] .def 

must also be provided. An example [project_rootname] .def hie for a simple 

two-body parameterization is shown below: 

set_mdf [project_rootname] .mdf 
default 1 DVl-Tl 0.00 
default 1 DV1-T2 0.00 
default 1 DV1-T3 0.00 
default 1 DV1-T4 0.00 
default 1 DV1-T5 0.00 
default 2 DV2-T1 0.00 
default 2 DV2-T2 0.00 
default 2 DV2-T3 0.00 
export model. tec. 1 
exit 
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The filename specified for the export command must be model. tec. 1. The 
remainder of the hie is dictated by the specihc parameterization developed in 
the Sculptor™ application. 

After the conhguration has been parameterized using Sculptor™ and all of 
the appropriate hies have been assembled for FuN3D-based design, a copy 
of the original [project_rootname] _massoud_bndry#.dat hie must also be 
placed in the description.! directory, but with the hie name changed to 
[project_rootname] .sdl. Sculptor™ requires this baseline hie during the op- 
timization. 

Finally, prior to performing the design, the [project_rootname] .sdl hie 
must be read into Sculptor™ in GUI mode as “Import Mesh/CFD as Tec- 
plot Point FE.” Following this, the Sculptor volumes need to be imported 
onto the [project_rootname] .sdl hie, and then the model must be saved 
again. Once this is done, the command export model. tec. 1 within the 
[project_rootname] .def batch script will generate a model.tec.l.sdl hie as 
needed for FuN3D-based design optimization. 

User-Defined Parameterizations In the event that a user-dehned geo- 
metric parameterization package is to be used, the user must provide a hie 
user.def _param_f iles.data. Since Fun3D will not be aware of any auxiliary 
hies that may be needed by the user-dehned parameterization package, those 
hies should be listed here, with a single hie name per line. Each hie named 
here must be provided by the user. At run time, Fun3D will move the named 
hies to the appropriate location prior to execution of the parameterization 
executable indicated by the user in ammo. input. See also section 9.3.4 and 
section 9.5.1. 


9.6.2 rubber, data 

This section describes how to set up each block of the design control hie 
rubber. data. The template provided in the Adjoint directory of the source 
code distribution is installed in the description.! directory during setup. 
This hie serves as the primary control hie during the course of the optimiza- 
tion and stores all of the high-level information relevant to the design. The hie 
is repeatedly read and updated by the various tools during the design proce- 
dure. A simple example of this hie to be used for discussion purposes is shown 
below. 


################################################################################ 
########################### Design Variable Information ######################## 
################################################################################ 


Global design variables (Mach number, 
Var Active Value 


ADA, Yaw, Noninertlal rates) 

Lower Bound Upper Bound 


Mach 

AQA 

Yaw 


0 

1 

0 


0 . 800000000000000E+00 

1 . OOOOOOOOOOOOOOOE+00 
0 . OOOOOOOOOOOOOOOE+00 


0 . OOOOOOOOOOOOOOOE+00 
0 . OOOOOOOOOOOOOOOE+00 
0 . OOOOOOOOOOOOOOOE+00 


0 . 900000000000000E+00 
5 . OOOOOOOOOOOOOOOE+00 
0 . OOOOOOOOOOOOOOOE+00 
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xrate 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

yrate 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

zrate 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

Number of bodies 
2 

Rigid motion design variables for 'wing' 

Var Active Value Lower Bound Upper Bound 

RotRate 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotFreq 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotAmpl 0 O.OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotQrgx 0 O.OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotOrgy 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotQrgz 0 O.OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotVecx 0 O.OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotVecy 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotVecz 0 O.OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

TrnRate 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

TrnFreq 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

TrnAmpl 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

TrnVecx 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

TrnVecy 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

TrnVecz 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

Parameterization Scheme (Massoud=l Bandaids=2 Sculptor=4 User-Def ined=5) 

1 

Number of shape variables for 'wing' 

3 

Index Active Value Lower Bound Upper Bound 

1 1 l.OOOOOOOOOOOOOOOE+00 O.OOOOOOOOOOOOOOOE+00 2.000000000000000E+00 

2 1 l.OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 2.000000000000000E+00 

3 1 l.OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 2.000000000000000E+00 

Rigid motion design variables for 'tali' 

Var Active Value Lower Bound Upper Bound 

RotRate 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotFreq 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotAmpl 0 O.OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotQrgx 0 O.OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotOrgy 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotQrgz 0 O.OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotVecx 0 O.OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotVecy 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

RotVecz 0 O.OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

TrnRate 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

TrnFreq 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

TrnAmpl 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

TrnVecx 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

TrnVecy 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

TrnVecz 0 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 0 . OOOOOOOOOOOOOOOE+00 

Parameterization Scheme (Massoud=l Bandaids=2 Sculptor=4 User-Def ined=5) 

2 

Number of shape variables for 'tail' 

2 

Index Active Value Lower Bound Upper Bound 

1 1 2.000000000000000E+00 -1 . OOOOOOOOOOOOOOOE+00 5.000000000000000E+00 

2 1 2.000000000000000E+00 -1 . OOOOOOOOOOOOOOOE+00 5 . OOOOOOOOOOOOOOOE+00 

################################################################################ 
############################### Function Information ########################### 
################################################################################ 
Number of composite functions for design problem statement 

2 

################################################################################ 
Cost function (1) or constraint (2) 

1 

If constraint , lower and upper bounds 
0.0 0.0 

Number of components for function 1 
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1 

Physical timestep interval where function is defined 
1 1 

Composite function weight, target, and power 
1.0 0.0 1.0 

Components of function 1: boundary id (0=all) /name/value/weight/target/power 

0 cl 0.000000000000000 1.000 10.00000 2.000 

Current value of function 1 

0.000000000000000 

Current derivatives of function wrt global design variables 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt rigid motion design variables of body 1 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt shape design variables of body 1 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt rigid motion design variables of body 2 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt shape design variables of body 2 
0.000000000000000 
0.000000000000000 

################################################################################ 
Cost function (1) or constraint (2) 

2 

If constraint , lower and upper bounds 
-0.03 -0.01 

Number of components for function 2 

1 

Physical timestep interval where function is defined 
1 1 

Composite function weight, target, and power 
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1.0 0.0 1.0 

Components of function 2: boundary id (0=all) /name/value/weight/target/power 
0 cmy 0.000000000000000 1.000 0.00000 1.000 

Current value of function 2 
0.000000000000000 

Current derivatives of function wrt global design variables 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt rigid motion design variables of body 1 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt shape design variables of body 1 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt rigid motion design variables of body 2 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 
0.000000000000000 

Current derivatives of function wrt shape design variables of body 2 
0.000000000000000 
0.000000000000000 


Global Design Variable Data This section of rubber. data lays out global 
design variables for the computation. These include the freestream Mach num- 
ber, angle of attack, and angle of yaw. For simulations using a noninertial ref- 
erence frame, the noninertial rotation rates about each of the three Cartesian 
coordinate axes are also available as design variables. 

Quantities associated with each variable are specihed on their own row 
in the hie and have several attributes that must be set by the user. The hrst 
column is a dummy index and is merely to assist the user in quickly navigating 
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through the hie. The second column is a toggle to activate the design variable. 
If this value is a 1, the variable will be allowed to change during the design. 
If the value is assigned a 0, this variable will be held constant at the value 
specihed. For incompressible hows and mixed-element grids, the Mach number 
must be declared inactive. Similarly, for hows posed in the inertial reference 
frame, the noninertial rates must be declared inactive. 

The third column in the design variable block is the current value for 
this design variable. The values of any active variables in this hie will take 
precedence over other input decks during design. For example, the how solver 
will run an angle of attack of 1 degree in this case, regardless of what may be 
specihed in funSd.nml. Columns four and hve specify the upper and lower 
bounds for the current design variable. 

Body-Specific Design Variable Data The next input following the Mach 
number and angle of attack entries specihes the number of bodies for which 
the user has provided shape parameterizations. Note that not every body in 
the grid must be included here. If the wing of an aircraft is the sole focus of 
the optimization, there is no need to account for other boundaries such as the 
tail or fuselage here. 

Following the number of bodies, there should be two blocks of design vari- 
ables for each desired body, namely a list of rigid motion variables controlling 
the dynamics of the body, and a set of shape parameters controlling the shape 
of the body. The columns of inputs are identical to those described above for 
Mach number and angle of attack. 

The bodies present in the computation may be listed in any order; how- 
ever, the order of their appearance in this control hie must match the integer 
suffix on their parameterization hies that are provided in the description.! 
directory, as well as hies such as body .grouping. data, transf orms.j, etc. 

The hrst section for the current body specihes design variables governing 
rigid body motion and is only applicable for time-dependent problems. For 
optimization of steady hows and/or static geometries, the rigid motion data 
is irrelevant but must be present in this hie. These variables should be set as 
inactive in these cases. 

The next block of inputs relates to the shape parameterization for the 
current body. First, the parameterization scheme is identihed by a scalar 
integer. The following values are available: (1) MASSOUD, (2) Bandaids, 
(4) Sculptor™, and (5) User-Dehned. The next input specihes the number of 
parameterized shape variables on the current body and the subsequent lines 
lay out the design variable information for that body. A row of data must 
be provided for every variable in the parameterization, whether it is active 
or not. (Note however, that internally, the optimizer is only made aware of 
the variables marked as active.) If a parameterization contains 25 variables, 
then 25 rows must appear in this corresponding block of rubber. data, even if 
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only a subset is active. If the design variable linking feature in MASSOUD or 
Bandaids has been used to create additional derived variables, they must also 
appear here. Note that the “Active” attribute for shape variables may take 
values of not only 0 or 1, but also —1 in certain multi-point design scenarios 
(see section 9.10). 

Care should be taken in choosing upper and lower bounds for shape vari- 
ables. Optimizers tend to fully explore the design space, which may result in 
infeasible shapes (or extreme shapes the mesh movement /solvers cannot han- 
dle robustly). Set these limits conservatively; one can always restart a design 
with less restrictive bounds. 

As noted previously, when using Sculptor™ parameterizations for multiple 
bodies, all such design variables must appear as a single concatenated body in 

rubber . data. 


Cost Function/Constraint Specification The hrst line following the de- 
sign variable block specihes the total number of composite functions to be used 
as objectives or constraints for the current design point. Multiple composite 
objective functions may be specihed in certain cases; see section 9.9. Other- 
wise, a single composite objective function must be specihed. The example 
hie shown here contains a single composite objective function based on the 
lift coefficient and a single explicit constraint based on the pitching moment. 
Note that explicit constraints may only be specihed if the optimization package 
chosen in ammo . input supports them. 

Following the scalar value specifying the total number of composite objec- 
tives and constraints, each composite function and/or constraint will have a 
block of data associated with it. Objective functions and constraints may be 
specihed in any order. 

The hrst two inputs in the composite function block specify a scalar integer 
indicating how the current function is to be viewed by the optimizer. The two 
subsequent inputs represent lower and upper bounds on the function if it is 
to be used as a constraint. If the function is an objective function, the hrst 
input value should be 1, and the lower and upper bounds must be present but 
their values are irrelevant. However, if the current function is to be used as 
a constraint, special attention must be paid to these inputs depending on the 
optimization package being used. 


Constraints Using NPSOL™ and SNOPT™ If the current function 
is to be used as an inequality constraint, the hrst input should be 2, and 
the lower and upper bounds should be set to their appropriate values. If the 
current function is to be used as an equality constraint, the hrst input should 
be 2; however, the lower and upper bounds should both be set equal to the 
desired constraint value. 
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Constraints Using KSOPT and DOT/BIGDOT™ These optimiza- 
tion packages assume constraint functions of the form / < 0, such that the 
bound of the feasibility region is implicit in the function dehnition and the 
lower and upper bound inputs must be present but are not used. If the cur- 
rent function is intended as an inequality constraint, the hrst input should be 
2. If the current function is intended as an equality constraint, the hrst input 
value should be 3. In this case, Fun3D’s design driver will provide the current 
function to the optimizer as an inequality constraint, but will also bookkeep 
an equal and opposite function as an additional inequality constraint. In this 
manner, an equality constraint is achieved by only allowing the intersection of 
the two inequality constraints as feasible. 

Following the classihcation of the current function, the next line states how 
many component functions comprise the current composite function. This can 
be any positive integer greater than or equal to 1. Following the number of 
component functions, the user must specify the physical time step interval over 
which the function is to be applied. This input is only relevant to optimization 
of unsteady hows. For steady hows, the values of these two inputs are ignored 
but must be present. 

The weight, target, and power to be applied to the current composite 
function are specihed next. These values are only relevant when combining 
multiple composite objective functions into a single global objective function 
(see section 9.9). For all other cases, these values should be specihed as 1.0, 
0.0, and 1.0, respectively. 

At this point, each component function that contributes to the current 
composite function has a line specifying several pieces of data. The hrst col- 
umn is the boundary patch over which to apply the current component. This 
index corresponds directly to the boundary patches in the CFD grid, and 
must rehect any patch lumping that is indicated in the &raw_grid namelist 
in funSd.nml (see section B.4.2). If a component function is to be used over 
the entire grid (total drag, for example), simply put a 0 in this column. Al- 
ternatively, if a single boundary patch is to be targeted, one might apply the 
component function to only that patch. Several patches may be targeted by 
including a component function for each. The next column is the keyword for 
the aerodynamic quantity to be used for the current function component. For 
a list of available keywords, see section 9.1. The next column contains the cur- 
rent value of the current function component. This is an output value during 
the optimization and need not be set by the user. The final three columns in 
the row correspond to the weight, target value, and power to be applied to the 
current component function in constructing the overall composite function. 

Current Function Value and Sensitivities Following the specihcation of 
the component functions, the next line of rubber. data contains the current 
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value of the composite function. This is an output and need not be set by the 
user. 

The remaining lines in the current function block contain the sensitivity 
derivatives with respect to all of the design variables listed in the top half of the 
hie. This section is divided into derivatives with respect to the global design 
variables, as well as the rigid motion and shape design variables for each of the 
bodies laid out in the top portion of the hie. These derivatives are outputs set 
by Fun3D and not by the user. However, a line for each design variable (both 
global variables as well as body-specihc variables) must be provided in each 
composite function block present. The values do not matter, but the solvers 
need positions available in the hie to store the current values. 


9.6.3 ae target.dat (optional) 

If the function keyword ae is specihed anywhere in rubber. data, the hie 
ae_target.dat must be present prior to performing the optimization. This hie 
provides the target equivalent area distribution(s) for each of the azimuthal 
locations specihed in the &equivalent_area namelist in funSd.nml (in the 
same order). See section 9.2.8 and section B.4.35. 


9.6.4 body -grouping, data (optional) 

This hie is used to specify body grouping information. For example, if the 
objective function is the Figure of Merit FM for a three-bladed rotor, then 
the three blades (each typically specihed as a separate parameterized body in 
rubber. data) should be associated into one group, so that sensitivity deriva- 
tives will rehect a composite d{FM)/dD for all three blades. This capability 
requires that the bodies to be associated all have identical parameterizations 
(same number of design variables on each body, etc). The format of the 
body -grouping. data hie is as follows: 


Number of groups to create 
1 

Number of bodies in group, list of bodies 
3 

12 3 


The hrst scalar integer specihes the number of groups to create (i.e., one rotor). 
The next set of inputs specihes the number of bodies in each group, followed 
by the bodies that comprise that group (i.e., each of the three rotor blade 
bodies). 
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9.6.5 command line . options (optional) 

The command_line . options file specifies any command line options to be nsed 
with the flow solver, the adjoint solver, or the MPI job lanncher (mpirun, 
mpiexec, aprun, etc). An example of this file is shown below. 

3 

1 flow 

' — rmstol l.e-7' 

1 adjoint 

' — rmstol l.e-3' 

2 mpirun 

' -nolocal ' 

' -machinef ile . . /machinef ile ' 

The first line of the file specifies the nnmber of programs for which command 
line options are being provided. The snbseqnent line mnst contain an integer 
followed by a keyword. The integer specifies how many command line options 
are being provided for the code identified by the keyword. The valid keywords 
are flow, adjoint, and mpirun. This line is followed by a line for each of the 
command line options provided for the code identified by the keyword. Each 
command line option shonld appear in single qnotation marks on its own line. 
The specified programs and their associated command line options may appear 
in any order. 

9.6.6 cpstar.data. j (optional) 

Fun 3D has an inverse design capability where the objective fnnction may 
be composed of target pressnre distribntions. The file containing the jth 
target distribntion must be named cpstar.data.j. However, setup is te- 
dious, primarily due to the difficulty in specifying pressure distributions on 
a three-dimensional conhguration. If this capability is of interest, please con- 
tact Fun3D-Support@lists.nasa.gov for more detailed guidance. 

9.6.7 f iles_to_save .data (optional) 

If desired, users may indicate specific files produced by the flow and adjoint 
solvers to be archived during an optimization. For example, custom visual- 
ization hies may be produced at each design iteration (see section 5.3.1) to 
enable animations of the design history after the optimization is complete. 

To specify certain hies to be archived during the course of a design ex- 
ecution, the user may provide the optional hie f iles_to_save.data in the 
description.! directory. Each line of the hie consists of one of two key- 
words, either “Flow” or “Adjoint”, followed by the specihc name of a hie to 
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be archived. For example, the following inputs could be used to archive Tec- 
plot™ hies containing solution data on boundaries for both the how and adjoint 
solvers, while also saving two additional Tecplot™ hies containing user-specihed 
sampling data for the how solution: 

Flow [pro j ect_rootname] _tec_boundary . dat 
Flow [pro j ect_rootname] _tec_sampling_geoml . dat 
Flow [pro j ect_rootname] _tec_sampling_geom2 . dat 
Adjoint [pro j ect_rootname] _tec_boundary . dat 

At the end of each function evaluation (i.e., how solution) for the ith design 
point, the hies [project_rootnamej_tec_boundary.dat, [project_rootname] 
_tec_sampling_geoml.dat, and [project_rootname] _tec_sampling_geom2.dat 
will be stored in the model. i/Flow/SaveFiles directory, with an integer cor- 
responding to the current design iteration appended to each of the hlenames. 
Similarly, the hie [project_rootname] _tec_boundary.dat will be stored in the 
model. i/Adjoint/SaveFiles directory at the completion of each sensitivity 
analysis (i.e., adjoint solution). 

9.6.8 machinefile (optional) 

If the optimization will be executed in an environment which requires an ex- 
plicit list of machines on which the MPI jobs will be executed, this hie must 
be present. It should take the format required of the particular MPI imple- 
mentation being used. If the optimization will be executed in an automated 
queuing environment, the job scheduler normally assigns the machines to be 
used at runtime and this hie is therefore not required. 

9.6.9 pressure_target.dat (optional) 

If the function keyword boom_targ is specihed anywhere in rubber. data, the 
hie pressure_target.dat must be present prior to performing the optimiza- 
tion. This hie provides the nearheld target p/poo distribution(s) for each of 
the oh-body locations specihed in the &sonic_boom namelist in funSd.nml (in 
the same order). See section 9.2.6 and section B.4.33. 

9.6.10 transforms.! (optional) 

Since MASSOUD uses a coordinate system specihc to an assumed aircraft 
orientation, it is sometimes necessary to reorient a body from its physical 
position to a MASSOUD-aligned coordinate system and vice-versa. Examples 
might include a vertical tail or the various blades of a rotor system. The hie 
describing the transform for the ith body should be included as transforms.!. 
The format of a typical transforms.! hie is as follows: 
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ROTATE 0.0 0.0 1.0 -120.0 


This would rotate the MASSOUD parameterization for the ith body by —120 
degrees about a unit vector in the +z direction. The commands TRANSLATE 
and SCALE are also available. 

9.7 Contents of the model, i Directory 

Just as for the description, i directories, the i in the model . i naming con- 
vention represents the design point index. This value is 1 for single point design 
or the design point index for multi-point design. The model . i directory con- 
tains the subdirectories Flow, Adjoint, and Rubberize. During the course 
of the design procedure, Fun3D will evaluate the relevant parameterizations 
and perform flow and adjoint solutions within these locations. These sub- 
directories are populated during the initial setup procedure with links to the 
required executables from the user’s Fun3D installation. Files in the model . i 
subdirectories should not be modihed by the user, although one may wish to 
observe various solver output hies during the course of the optimization. All 
user-provided inputs are conhned to hies located in the description.! and 
ammo directories. 

9.8 Running the Optimization 

Once all of the required inputs and hies have been provided, the user should 
hrst request a single function evaluation from the optimization driver. This is 
strongly recommended in order to identify any potential issues in the various 
inputs. To perform this check, set the value of Operation to perform in 
ammo . input to 1, and execute the optimization driver from the ammo subdi- 
rectory: 

opt_driver > screen. output & 

Here, the output from the optimization driver has been redirected to a hie 
called screen. output. This hie is very useful if a problem needs to be diag- 
nosed with the execution. It is also good practice to include this hie with help 
requests to Fun3D-Support@lists.nasa.gov. 

At the completion of the function evaluation, the user should check for the 
desired/expected result. This is also a good opportunity to establish reason- 
able values for the number of time steps to run, the residual tolerance at which 
the solver should quit, and so forth. Such run control parameters may be set 
in funSd.nml or via the commandAine . options hie. 

Once the function evaluation procedure has been verihed, the user should 
perform the same test for a sensitivity analysis by setting Operation to 
perform in ammo . input to 2 and re-executing the optimization driver. Similar 
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checks on convergence parameters, etc for the adjoint solver should be noted 
and applied to the relevant input hies. 

With successful function and gradient evaluations in hand, an actual opti- 
mization may be initiated. The value of Operation to perform in ammo . input 
should be set to 3, and the optimization driver can be executed as before. The 
user should closely monitor the screen output as the process proceeds, espe- 
cially during the hrst several design cycles when input parameters may hrst 
cause problems. The largest changes in design variables often occur early on 
as well, which can cause issues with mesh movement operations, solver con- 
vergence, and other aspects. It is also very useful to occasionally hlter the 
screen output for the current function value (s) reported at the completion of 
each how solution in order to monitor overall progress: 

grep "Current value of function" screen. output 

When an optimization completes, the optimizer will report the reason for 
the termination to the screen, which may be a local minimum, or some prob- 
lem encountered during the simulation. A summary of the optimization is 
provided by each optimization package in the hle(s) noted in Table 12. The 
hnal set of design variables and function/constraint values determined by the 
optimizer will be available in model, i/rubber. data. To track the history of the 
optimization, a backup of all intermediate copies of rubber. data are stored 
in the directory model. i/Rubberize/surface_history. Intermediate copies 
of the surface grids developed during the design process are also stored in this 
location as model. tec. j.sdl. iter, where j is the body index, and iter is the 
design iteration. These hies may be used to produce animations of the surface 
history if desired. Using the broad range of visualization output options for 
the solvers, the user has great freedom to produce customized animations of 
the design history (see section 9.6.7). 

Table 12: Files containing design summary from various optimization packages. 


9.8.1 Filesystem Latency Problems 

Design optimization using some cached hie systems may experience problems 
due to the rapid execution of the various tools during the design process. In 
some cases, a hie system lag may cause some processes to receive older/stale 


Optimization Package Summary File(s) 


DOT/BIGDOT™ 

KSOPT 

PORT 

NPSOL™ 

SNOPT™ 


dot. output 
ksopt. output 
port. output 

npsol.printfile, npsol.summaryfile 
snopt.printfile, snopt.summaryfile 
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versions of files during execution. Specifying the — sleep_delay [seconds] 
command line option to the opt_driver executable will pause the optimization 
process with a sleep duration of seconds between subsequent code executions 
to allow the hie system to perform correctly. On older systems, delays as large 
as 60 seconds are sometimes necessary; more recent systems seem to perform 
considerably better and values of 5-10 seconds are often sufficient. 

9.9 Multi-objective Design 

KSOPT, PORT, and SNOPT™ are the only packages currently supported for 
use with multi-objective design. Details on the usage for each package are 
provided below. 

9.9.1 KSOPT 

KSOPT is the only supported optimization package with explicit support for 
multiple objective functions. When using KSOPT, the user may designate any 
number of composite functions as objective functions in rubber. data. 

9.9.2 PORT, SNOPT™ 

The Fun 3D design driver offers a simple approach to scalarizing multiple user- 
specihed objective functions for use with the PORT or SNOPT™ packages. If 
multiple composite functions are specihed in rubber. data, the Fun 3D design 
driver will combine them using the weight, target, and power values specihed 
at the composite function level (i.e., the input values that appear just before 
the component function data is specihed in rubber. data, see section 9.6.2). If 
N composite functions / are labeled as objective functions in rubber. data, the 
scalarized objective function F to be provided to the optimization procedure 
will take the form 

F = «i(/i - /n™ + «2(/2 - f;r + - + «iv(/7v - (12) 

where /*, and pi are the weight, target, and power values associated with 
each composite function in rubber. data. 

9.10 Multi-point Design 

The Fun 3D design infrastructure ohers several approaches to multi-point op- 
timization. This refers to design problems where the user may wish to simul- 
taneously optimize a conhguration for operations at two diherent conditions 
— perhaps the beginning and end of a cruise segment for example, where the 
aircraft weight may be substantially diherent. The user may also wish to de- 
sign for cruise and takeoh or landing (or all three). The various design points 
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may be characterized by different ffow conditions (i.e., speed, angle of attack, 
etc), or more generally, by the geometries (and therefore grids) at each point. 
For example, one design point may consist of a cruise geometry operating at 
Mach 0.8, while another design point may be a landing configuration operating 
at Mach 0.2 with a high-lift system deployed. For examples of FuN3D-based 
multi-point design in practice, see the studies in [13] and [21]. In these ref- 
erences, a tilt-rotor geometry has been optimized for a set of several blade 
collective settings as well as hover and forward flight conditions. 

To perform a multi-point optimization, the user must request the desired 
number of design points when setting up the directory structure where the 
design will be performed (see section 9.4). The user must populate each of the 
description.! directories for each design point i just as in the single-point 
design context. The order of the design points does not matter. The value 
of Number of design points in ammo. input should be set appropriately. Ul- 
timately, Fun 3D provides several ways to formulate the multi-point design 
problem. These approaches are outlined below. 

In general, the optimizer will be seeking a unique set of design variables 
to simultaneously achieve goals at all of the design points. For this reason, a 
consistent set of design variables across all design points must be used. This 
applies to the global variables Mach number and angle of attack as well as any 
body-specific variables such as shape parameters. For example, if a set of 15 
thickness variables is provided for a wing shape in cruise, other design points 
(again, perhaps a landing configuration as an example) must utilize the same 
set of 15 thickness variables. Moreover, the same subset of design variables 
must be active at each design point. 

Multi-valued Design Variables In some situations, the user may desire 
different optimal values of a design variable at different design points. For 
example, consider power minimization for a rotor in hover at two different 
weight conditions, where each of the two design points may have different 
minimum thrust coefficients posed as constraints. In addition to other design 
variables that may be present, the user may have a shape parameter controlling 
the blade collective setting (blade pitch). However, rather than constraining 
the optimal blade collective to a single unique value, the user may desire 
separate, optimal values for each design point. As another example, consider 
a configuration with an ability to actively morph its outer mold line. In this 
case, the user may wish to determine optimal values of the shape parameters 
that are unique to different design points. 

To accommodate such multi-valued design variables, the user may set the 
“Active” attribute for individual shape design variables to —1 in rubber. data 
(see section 9.6.2). If this is done, it must be applied consistently for that 
same variable across all design points. For variables with this attribute, the 
Fun 3D design driver will internally bookkeep separate values of the variable 
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for each design point. This feature is currently only available for use with the 
SNOPT™ package. 

9.10.1 Linear Combination of Objective Functions 

The most straightforward approach to multi-point design is to linearly combine 
individual objective functions /* from each of the N design points i into a single 
global objective function f^p- 

fmp = otifi + 02/2 + tts/s + + ocnIn (13) 

To perform the optimization in this fashion, a single composite objective func- 
tion should be posed in each description. i/rubber. data hie. Each of the 
weighting coefficients must be specihed as Weights for each design point 
in ammo. input, in the corresponding order. 

This form of multi-point design is supported by PORT, DOT/BIGDOT™, 
and SNOPT™. Note that PORT and SNOPT™ will also combine multiple 
objective functions within each design point as described in section 9.9 if de- 
sired. Explicit constraints can be posed at each design point when using 
DOT/BIGDOT™ or SNOPT™; such constraints are each treated individually. 

9.10.2 Combination of Objective Functions using the Kreisselmeier- 
Steinhauser Function 

Another alternative for performing multi-point design is the approach inher- 
ent in the KSOPT package. In this approach, all objective functions and 
constraints are combined using the Kreisselmeier-Steinhauser (KS) function. 
The user is referred to [22] for the details of this formulation. Here, the Fun3D 
design driver gathers any number of objective and constraint functions across 
all design points and provides them to KSOPT, which internally constructs 
its KS function for the actual optimization problem. 

9.10.3 Single-Point Objective Function with Off-Design Constraint 
Functions 

In this approach to multi-point design, a single objective function is provided 
to the optimizer, while all other functions are treated as explicit constraints. 
Here, the user should designate a single composite function across all of the 
description. i/rubber. data input hies as an objective function. Any other 
composite functions at each design point should be designated as constraint 
functions. KSOPT, SNOPT™, and NPSOL™ support this form of multi-point 
optimization; SNOPT™ can also construct the hnal objective function by lin- 
early combining multiple objective functions within the desired design point 
as described in section 9.9. 


9.11 Optimization of Two-Dimensional Geometries 

While the Fun3D flow solver supports a 2D mode of operation, this capability 
is not currently available from within the design infrastructure. Instead, the 
optimization must be performed as a pseudo-3D case. The user should pro- 
vide a nominally two-dimensional grid, with a single layer of elements in the 
spanwise (y) direction. The mesh should consist of either prisms or hexahedra 
(or both), but should contain no pyramids or tetrahedra. Follow the same 
procedure used for 3D cases to extract the surface grid for parameterization. 
The surface should be parameterized just as for a 3D simulation; however, the 
parameterization should allow no spanwise asymmetries in the geometry to 
develop. When using MASSOUD or Bandaids, this is readily accomplished 
by linking the raw parameters with an equal weighting across the span into a 
single set of design variables that operate in a chordwise fashion. Note that 
the sidewalls should use symmetry _y boundary conditions so that only in-plane 
mesh deformation occurs during the optimization. The design may now be ex- 
ecuted as usual, with the 2D nature of the problem enforced implicitly through 
the parameterization. 

9.12 Using a Different Optimization Package 

In a CFD-based design context, the term “function” implies an evaluation of 
the geometric parameterization, mesh movement (both surface and volume), 
a flow solution, and an evaluation of the output function/constraint for a 
given set of design variables. The file manipulations and solver operations 
necessary to achieve this are not trivial. For users interested in using the 
tools as “black boxes” providing function data for an optimization package, a 
wrapper has been provided in the LibF90 directory of the distribution named 
analysis. f 90. This module contains a subroutine called perf orm_analysis () 
which performs the extensive set of tasks involved with producing the final 
desired function output. 

To obtain sensitivities, the Fun3D package relies on a discrete adjoint for- 
mulation. As with function evaluations, the low-level operations required to 
perform an adjoint-based sensitivity analysis are numerous. A wrapper routine 
called perf orm_sensitivity_analysis 0 in the LibF90/sensitivity.f90 
module will perform an adjoint solution for the flow field, an adjoint solu- 
tion for the mesh movement scheme, an evaluation of the linearized geometric 
parameterization, and Anally produce the desired sensitivity derivatives. 

The Fun3D design driver uses the wrappers perf orm_analysis () and 
perf orm_sensitivity_analysis 0 to greatly simplify function and gradient 
evaluations when connecting to off-the-shelf optimization packages. If the 
user wishes to implement a new optimization strategy, it is highly recom- 
mended that these wrappers be used in a similar fashion. A review of the 
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existing modules in the Design directory of the Fun 3D source code distribu- 
tion, which implement the currently available optimization interfaces, is also 
strongly suggested. Users may contact Fun3D-Support@lists.nasa.gov for 
further guidance in leveraging Fun3D’s capabilities from within their own 
existing design framework. 

9.13 Implementing New Cost Functions /Constraints 

Implementation of new cost functions or constraints is not a trivial undertak- 
ing and requires extensive modihcation of Fun 3D source code. Experience 
in Fortran 2003, unstructured-grid discretizations, development in a domain- 
decomposed/distributed-memory environment, and general CFD methods are 
essential. Routines to evaluate the proposed function and linearizations of the 
function with respect to both the flow held variables and grid are ultimately 
required. The complex-variable form of Fun 3D (see section 9.14) is invalu- 
able in verifying the accuracy of these linearizations. It is highly recommended 
that the user contact Fun3D-Support@lists.nasa.gov for guidance prior to 
attempting the implementation of a new cost function or constraint. 

9.14 Forward Mode Differentiation Using Complex 
Variables 

The reverse, or adjoint, mode of differentiation is primarily used for design 
with Fun3D. a forward mode of differentiation is also provided based on the 
use of complex variables [23-25]. This capability is useful for design problems 
containing few design variables and many cost functions or constraints. To 
generate and build a complex-variable Fun 3D executable, see section A. 5. 

The complex- valued how solver reads the usual real- valued grid hies and is 
set up to compute derivatives of every output variable with respect to Mach 
number, angle of attack, shape parameters, non-inertial rotation rates, or the 
X, y, or ^ coordinate of a single grid point (others are trivial to add). This 
choice is controlled by the hie perturb. input. A template for this hie is 
provided in the FUN3D_90 directory and an example is also shown below. 

PERTURB EPSILON GRIDPOINT 

2 l.e-50 666 

0 = No perturbation 

1 = Mach number 

2 = Alpha 

3 = Shape 

4 = x-rotation rate 

5 = y-rotation rate 

6 = z-rotation rate 


7 = Grid point x 

8 = Grid point y 

9 = Grid point z 

10 = Yaw 

100+ = add an imaginary source term to equation 
PERTURB-100 of node GRIDPOINT 
(to verify the adjoint lambda value) 


The value of PERTURB specifies the variable for which sensitivities will be 
taken with respect to. The valid integer values are as shown above. The input 
EPSILON specihes the magnitude of the imaginary perturbation to be applied. 
The recommended value is l.e-50. If the value of PERTURB is greater than 
six, the value of GRIDPOINT specihes the grid point index to perturb. The 
remaining lines in perturb, input are not read; they are simply reminders of 
the valid inputs just described. The complex-valued how solver may then be 
executed in a manner similar to the real- valued how solver: 

mpirun . /complex_nodet_mpi 

To compute derivatives with respect to a shape parameterization variable, the 
sensitivities of the parameterization must hrst be evaluated in the directory 
model . i/Rubberize using the relevant parameterization software. The value 
of PERTURB should be set to 3 in perturb . input. The complex-valued how 
solver can then be executed in the following fashion: 

mpirun . /complex_nodet_mpi — dv_index [body] [dv] — snap_grid 

Here, the values of body and dv specify the body and design variable index in 
rubber . data to which to apply the imaginary perturbation. The — snap.grid 
argument forces the how solver to propagate the surface sensitivities into the 
volume mesh using Fun3D’s elasticity-based deformation mechanics. 

At the completion of the complex-valued how solve, outputs will contain 
both real and imaginary parts. The imaginary part represents the sensitivity 
of that output with respect to the perturbation variable that was specihed in 
perturb . input. 
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Appendix A 


Installation 


Fun3D is distributed as gzipped archive of source code. The GNU build 
system is used to package and install Fun3D. The required installation steps 
are detailed in this section. Due to the large range of capabilities, conhguring 
the dependent packages is the most involved step and is the focus this section. 
As was illustrated in the Quick Start section, four basic steps are required: 

1. Extract the source code from the gzipped tarball archive with tar 

2. Conhgure the desired dependencies and compiler options with conf igure 

3. Compile via make 

4. Install the compiled binaries and supporting scripts via make install 

If any difficulties arise with the installation process please, send the entire 
config.log hie produced by configure and the full stdout and stderr of make 
to Fun3D-Support@lists.nasa.gov. The user is strongly advised against 
editing the configure script or any Makefile it produces. We are unable to 
assist users who have edited these hies. 

A.l Extracting Files 

After downloading the source code as a gzipped tarball, the user can unpack 
it with 

tar zxf fun3d-12.6-*.tar.gz 

which will create the directory fun3d-12 . 6-*. (The * represents a code that 
the Fun3D uses internally to version the code.) If you have do not have a 
GNU-compatible tar, you may have to insert a separate decompression step, 
i.e.. 


gzip -d fun3d-12.6-*.tar.gz | tar zxf - 

A. 2 Configure Introduction 

The Fun 3D suite of tools is conhgured and built via the GNU build system 
and must be conhgured hrst. Change to this directory, e.g., cd fun3d-12 . 6-*, 
and execute 

./configure — help 
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to see a list of all available compilation options. When configure is invoked, 
detailed results of all the tests it performs are written to the hie conf ig. log. 
Some features of the conhgure step that have caused problems for users 

are: 

• An incorrect spelling of a — enable-* or — with-* option is silently 
ignored. This will result in the intended option not being included in 
the compiled executable. 

• Option values containing spaces must be quoted to be correctly inter- 
preted by the shell (i.e., FCFLAGS=’ -optionl -option2’). 

• If the configure command is executed more than once with different 
options, make clean is required before the make step, so that changes 
to the conhguration are correctly rehected in the compiled executable. 

A. 3 Alternative Installation Path 

The path to the installation directory is specihed by the — prefix= option. 
The default is to install to /usr/local with executables placed in /usr/ 
local/bin. This default location may not be available if the user does not have 
write permission to this directory (without root or administrator privileges). 

To install to an alternative path (e.g., $H0ME/local), use the — prefix= 
option to set the installation path 

./configure — pref ix=$HOME/local 

Finally, to include the Fun 3D executables in the command search path, add 
setenv PATH $HOME/local/bin: $PATH 
to the ~/.cshrc hie or the equivalent for your shell. 

A. 4 Fortran Compiler Option Tuning (FTune) 

By default, configure will use compiler and linker options chosen by the 
Fun 3D team. The process is referred to as “FTune.” The users PATH is 
searched in a predehned order until the hrst FuN3D-compatible compiler is 
found. When conhgured with MPI, the build will use mpif90 located in the 
bin directory of the given MPI installation."^^ However, the user can explicitly 
specify the desired Fortran compiler via the FC environment variable. 

To directly specify the compiler and linker options, use the FCFLAGS and 
LDFLAGS environment variables. The default behavior is to append their values 
to the options dehned by FTune. If the — disable-ftune option is given 
to configure, FTune will be disabled and the values given by FCFLAGS and 

see what the underlying compiler is, use mpif90 -show. 
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LDFLAGS will be used explicitly. For example, to ensure that the Intel® Fortran 
compiler ifort is used with only the -03, -ip, and -Im options, 

./configure — disable-f tune \ 

FC=ifort \ 

FCFLAGS='-03 -ip' \ 

LDFLAGS= ' -Im ' 

The order of variables and options are inconsequential, and single quotation 
marks ( ' ) are used to protect values with spaces from the shell. Some FTune 
options may be unconditionally required for a given compiler, as in the case of 
linking with the math library -Im above. 

A. 5 Complex Variable Version 

The Fun 3D suite can be complied with the real variables in the code re- 
placed with complex variables by a source translation tool. This permits 
the computation of forward-mode sensitivities, see section 9.14 for details. 
To enable, add the --enable- complex conhgure option to the configure 
script. The complex-valued code can be compiled with make complex; and a 
make install will place the complex-valued executables in the bin installa- 
tion directory. Enabling the complex variable version will increase the compile 
time. 

A. 6 Internal Libraries 

Fun 3D has internal dependencies to libraries that are distributed with Fun 3D. 
These libraries are automatically built and linked to Fun 3D by default. 

A.6.1 KNIFE 

The KNIFE cutcell library provides cutcell capabilities. The --without-knif e 
option will disable this library. 

A. 6. 2 REFINE 

The REFINE library provides access mesh adaptation and untangling capabil- 
ities. The --without-ref ine option will disable this library. 

A. 7 External Libraries 

Fun 3D relies on external libraries to enable some of its advanced applications. 
Use Table Al to determine which set of external libraries are necessary for your 
applications of interest. Discussions of each external library are found in the 
following sections. 
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Table Al: Configuration options. 
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ParMETIS 

X 






SUGGAR 


X 





DiRTlib 

6-DOF 

KSOPT 


X 
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X 


PORT 

SNOPT™ 




X 

X 


NPSOL™ 





X 


DOT/BIGDOT™ 





X 


Tec plot™ 






X 

GGNS 







SBOOM 








It is highly recommended that Fun 3D is conhgured to use a parallel execu- 
tion (MPI and ParMETIS) if you plan to perform any advanced calculations. 
SUGGAR-I--I- and DiRTlib are only required if overset (chimera) meshes will 
be used. The 6-DOF library is only required if six degrees of freedom simu- 
lations will be performed (trajectories determined by integrating the equation 
of motion). KSOPT, PORT, SNOPT™, NPSOL™, and DOT/BIGDOT™ are 
optimization libraries. At least one of these optimization libraries is required 
for performing design optimization. 

A. 7.1 MPI 

MPI provides Fun3D’s capability to communicate between processors. Gon- 
hgure with the option 

— with-mpi=/path/to/MPI 

where /path/to/MPI is the directory where MPI is installed. 

In addition, Fun 3D must be executed in an environment that repre- 
sents the same MPI installation used for conhguration/compilation (e.g. same 
mpiexec, mpirun, etc.). Failure to provide such consistency will result in un- 
dehned behavior and undetermined segmentation faults. 

In some cases, MPI may already be installed on the target machine. If it is 
not, OpenMPI or MPIGH can be used and the option of static MPI libraries 
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is recommended. Also, if building OpenMPI or MPICH from source, it is 
important to maintain consistency with compilers (both vendor and version) 
throughout the build and execution of Fun3D and its dependent libraries. 

For example, if OpenMPI is built with gfortran version 4.4.7, then the ex- 
ecution environment for Fun3D must reflect the same vendor and version, 
gfortran 4.4.7. Fun3D execution must also employ the same mpiexec from 
the OpenMPI installation used to build the software. 

Some high performance computing environments use a proprietary MPI 
implementation that does not provide mpif90. It that situation, the conhg- 
ure option — without -mpif 90 may be required in combination with the FC 
environment variable to explicitly set the compiler. 

Verifying the MPI Implementation Functionality A simple Fortran 
program is included in the FUN3D distribution to verify that the MPI imple- 
mentation is functional. This is very helpful for quickly troubleshooting issues 
with the MPI implementation. It is located in utils/MPIcheck. From within 
that directory you should be able to 

mpif 90 -o mpi_hello_world mpi_hello_world.F90 

and execute on two processors 

mpiexec -np 2 . /mpi_hello_world 

0 says, "Hello World!" 5=5 

1 says, "Hello World!" 5=5 

To verify the Fortran compiler that MPI is built with, try 
mpif90 -show 

if the MPI implementation supports it. 

A.7.2 ParMETIS 

Website: http : //glares. dtc.umn.edu/gkhome/metis/parmetis/overview 

The partitioning library ParMETIS is required for parallel execution. ParMETIS 
is a parallel graph partitioner that is used to perform domain decomposition 
for all parallel Fun3D jobs. It is critical that Fun3D and ParMETIS are 
compiled with exactly the same MPI installation and compilers. This includes 
the C compiler used to compile MPI, ParMETIS, and FUN3D. 

When conhguring Fun 3D, use 

— with-parmetis=/path/to/ParMETIS 

where /path/to/ParMETIS is the directory of the ParMETIS installation. 
Fun3D expects the /path/to/ParMETIS directory to contain the following 
hies in lib and install subdirectories. 
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/path/to/ParMETIS/lib/libmetis . a 
/path/to/ParMETIS/lib/libparmetis . a 
/path/to/ParMETIS/include/metis .h 
/path/to/ParMETIS/include/parmetis .h 

See the Install.txt instructions in the ParMETIS distribution for build 
instructions. Fun3D requires both libmetis.a and libparmetis.a libraries 
and their accompanying header hies. There is an example of commands to 
build both libraries, 

cd parmetis-4 . * 

make config pref ix=/path/to/ParMETIS 
make install 
cd metis 

make config pref ix=/path/to/ParMETIS 
make install 

where /path/to/ParMETIS matches the Fun 3D conhgure argument. 

A. 7. 3 SUGGARH — h-1-0.10 or Higher 

Website: http : / / celeritassimtech.com 

SUGGAR++ is used for overset (chimera) applications and assembles com- 
posite meshes, cuts holes, determines interpolation coefficients, etc. If conhg- 
uring with SUGGAR-|--|-, Fun3D must also be conhgured with DiRTlib vl.40 
or higher. 

SUGGAR-I--I- may be compiled as a stand-alone executable and/or as a li- 
brary. For static overset meshes you will need the stand-alone compilation; for 
moving body simulations you will need to compile both the stand-alone exe- 
cutable and the library. See the documentation that comes with SUGGAR-I--I- 
for more information on how to compile the software. 

When conhguring Fun 3D, use 

— with-suggar=/path/to/SUGGAR++ 

where /path/to/SUGGAR++ is the directory where SUGGAR-|--|- library archive 
hies (.a hies) reside. In this directory, there must be an archive hie called 
libsuggar.a, which is the serial compilation of SUGGAR-|--|-, and there must 
also be an archive hie called libsuggar_mpi.a, which is the MPI compilation 
of SUGGAR++. 

A. 7. 4 DiRTlib vl.40 or higher 
Website: http : / / celeritassimtech.com 
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The DiRTlib library must be linked to Fun 3D in order to use the overset 
connectivity data computed by SUGGAR++-1.0.10 or Higher. See the docu- 
mentation that comes with DiRTlib for more information on how to compile 
the software. 

When conhguring Fun 3D, use 
— with-dirtlib=/path/to/DiRTlib 

where /path/to/DiRTlib is the directory where DiRTlib library archive hies 
(.a hies) reside. In this directory, there must be an archive hie called libdirt.a, 
which is the serial compilation of DiRTlib, and there must also be an archive 
hie called libdirt_mpich.a, which is the MPI compilation of DiRTlib. 

A. 7.5 6-DOF 

Gont act : N athan. G . Prewitt @usace. army. mil 

The 6-DOF libraries provide trajectory tracing. When conhguring Fun 3D, 
use 


— with-sixdof =/path/to/sixdof 

where /path/to/sixdof is the directory where your 6-DOF installation re- 
sides. 

A. 7.6 KSOPT 

Gontact: Gregory.A.Wrenn@nasa.gov 

The KSOPT [22] library is used for multi-objective and constrained Fun 3D- 
based design optimization. If you conhgure Fun 3D to link to KSOPT, you 
must use the Fortran 90 implementation of KSOPT with its object hies gath- 
ered into a library called libksopt.a. 

When conhguring Fun 3D, use 

— with-KSOPT=/path/to/ksopt 

where /path/to/ksopt is the directory where your KSOPT installation re- 
sides. 

A. 7.7 PORT 

Website: http : //www.netlib.org/port 

The PORT library is used for unconstrained FuN3D-based design opti- 
mization. The Netlib site ohers a tarball of the PORT library with a Makefile. 
Download the tarball from Netlib, but replace the original Makefile with the 
hie included inside the Fun 3D distribution as Design/PORT. Makefile. If you 
install both the PORT and NPSOL™ libraries, you may have to comment out 
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low-level BLAS routines in one of the two packages because the linker will 
report the duplicate versions of these routines. 

When conhguring Fun 3D, use 

— with-PORT=/path/to/port 

where /path/to/port is the directory where your PORT installation resides. 

A.7.8 SNOPT™ 

Website: http : //www.sbsi-sol-optimize.com 

The SNOPT™ library is used for FuN3D-based design optimization. By 
default the SNOPT™ package builds a shared library. Either build SNOPT™ 
with the --disable-shared option, or add the the SNOPT™ install directory 
to your LD_LIBRARY_PATH environment variable to ensure Fun3D can End the 
shared library at run time. 

When configuring Fun 3D, use 

— with-SNOPT=/path/to/ snopt 

where /path/to/snopt is the directory where your SNOPT™ installation re- 
sides. 

A.7.9 NPSOL™ 

Website: http : //www.sbsi-sol-optimize.com 

The NPSOL™ library is used for constrained FuN3D-based design opti- 
mization. If you install both the PORT and NPSOL™ libraries, you may have 
to comment out low-level BLAS routines in one of the two packages because 
the linker will report the duplicate versions of these routines. 

When conhguring Fun 3D, use 

— with-NPSOL=/path/to/npsol 

where /path/to/npsol is the directory where your NPSOL™ installation re- 
sides. 

A.7.10 DOT/BIGDOT™ 

Website: http : //www. vrand.com/products.html 

The DOT/BIGDOT™ library is used for unconstrained or constrained 
FuN3D-based design optimization. When conhguring Fun 3D, use 

— with-DOT=/path/to/dot 

where /path/to/dot is the directory where your DOT /BIGDOT™ installation 
resides. 
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A. 7. 11 Tecplot™ 


Website: http://www.tecplot.com 

By default, any Tecplot™ output generated from within the flow solver itself 
is written as a text hie. If you have a copy of Tecplot™, you were provided 
with a library archive tecio.a (or tecio64.a for 64-bit versions) that allows 
for binary output. You may conhgure the Fun3D suite to use the library 
via: 

— with-tecio=/path/to/tecio 

With this option, Tecplot™ solution data written out from the how solver will 
be in binary form. This results in smaller hie sizes and faster importation into 
Tecplot™. 

If you have compiled against the Tecplot™ tecio library, you can still 
request text output via the --ascii_tecplot_output command line option. 

A. 7.12 CGNS 

Website: http://www.cgns.org 

The CGNS library is used for working with hies written in CGNS format. 
CGNS is a convention for writing machine- in depen dent, self-descriptive data 
hies for CFD and includes implementation software. Fun 3D has the capability 
to translate and write CGNS hies. The translation utilities are only compiled 
when CGNS is conhgured. Version 2.5 or greater of the CGNS library is 
required. To include GGNS, use 

— with-CGNS=/path/to/ cgns 

where /path/to/ cgns is the directory where the GGNS installation resides. 

A. 7.13 sBOOM 

Gontact: Sriram.Rallabhandi@NASA.gov 

This package propagates a computed pressure signature to the ground for 
sonic boom simulations. Atmospheric variations are included, and an adjoint 
version is available for coupling into design and grid adaptation. sBOOM is 
distributed as a standalone executable or a static library. Fun3D is not able 
to interact with the standalone executable; the static library must be linked. 
You may conhgure the Fun3D suite to use the library via: 

— with-SBOOM=/path/to/ sBOOM 

where /path/to/sBOOM is the directory where the sBOOM installation re- 
sides. 

^^The tecio library that was shipped with Tecplot 360-2008 had a bug that will result 
in error messages when the binary files are written. You must get an updated version of the 
library. 
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Appendix B 


Fun 3D Input Files 


There are a variety of input files necessary for the various codes that make 
up the Fun 3D suite. Table B1 lists frequently used input hies with a short 
description. This chapter will describe the basic formats of each of these hies 
and meaning of the specihc inputs they contain. 


Table Bl: Fun3D input files. 

File Description 


stop.dat 

remove _boundar ies_from_force .totals 

[project_rootname] .flow* 

funSd.nml 

moving.body. input 

rotor. data 

tdata 

kinetic.data 
species_transp_data 
species_transp_data_0 
bar a jname 1 i st _dat a 


signals a change to the number of iterations / 
time steps that were requested at the beginning 
of the run 

omits boundary faces from total force integra- 
tion 

flow field solution 

primary Fortran namelist (required) 

body motion Fortran namelist 

describes the rotor actuator disk model 

specifies the generic gas model 

specifies the possible chemical reactions in the 

generic gas model 

specifies generic gas model species collision cross 
sections 

specifies a higher-order generic gas model 

species collision cross sections 

controls the radiation models used by the Hara 

library 


* The [project.rootname] is a feproject namelist variable, see section B.4.1. 


Fun 3D utilizes Fortran namelists for a large portion of input specihcation 
because it is dehned in the Fortran 90 standard. With all Fortran namelists, 
leaving out or misspelling any namelist (dehned with an ampersand preceding 
its name) will result in default values being used for all of the parameters within 
that namelist. For example, if the namelist name linear_solver_parameters 
were to be misspelled as linear _solver_parameter (missing s), then all pa- 
rameters within that namelist would be ignored and retain their default values. 
Leaving out any parameter within a namelist results in the default value for 
that parameter being used. Misspelling or misusing any particular parameter 
will typically cause Fun 3D to issue an error and stop. 
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B.l stop.dat 

This optional file either halts or extends the execution of the solver. The 
stop.dat plain text file contains a single integer. After every iteration, the 
solver will check to see if this file exists. If the file is found in the directory 
that the solver was invoked, the integer is read. If the integer is greater than 
zero and less than or equal to the current iteration, the solver will write the 
current solution, delete the stop.dat hie, and halt execution. If the integer 
is less than zero, the solver will not write the restart hie, but will delete the 
stop.dat hie and halt execution. If the integer is greater than the current 
iteration, code execution will proceed until the iteration matches the integer, 
and the solver will write the current solution, delete the stop.dat hie, and 
halt execution. The value of the integer may be greater than the number of 
iterations / time steps specihed in funSd.nml, so that stop.dat can be used 
to extend the execution of the solver if desired. 

Some environments, especially ones with network-mounted hlesystems (e.g., 
NFS), may result in a delay with the stop.dat hie being read or being deleted. 

B.2 [project_rootname] .f low 

The optional [project_rootname] .flow binary hie contains how solution and 
checkpoint information. The [project_rootname] is a feproject namelist 
variable, see section B.4.1. This hie is read by the solver to restart compu- 
tations from a previously computed how solution. The contents vary due to 
the checkpoint requirements of the simulation. The hie contains a minimum 
of the current solution and convergence history. It can also contain working 
variables for the turbulence model, solutions from previous iterations for time 
accurate cases, or previous grid positions and velocities for deforming grids. 

B.3 remove boundaries from force totals 

The optional remove_boundaries_f rom_f orce_totals hie is for specifying bound- 
aries that are not to be included in the calculation of force and moment totals. 
This hie is useful, for example, in situations where there may be a mounting 
sting on a wind tunnel model, but only the forces on the model are actually of 
interest. The forces on the specihed boundaries are still computed and appear 
in the [project_rootname] .forces hie. However, they are not included in 
the totals. The position of the text lines in this hie is signihcant. So, follow 
this template carefully: 

Remove selected boundaries from the total forces 

Number of boundaries to turn off 

2 

Boundaries to turn off (boundary lumping changes indexes) 
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12 

15 

The third line is the number of boundaries to exclude. The hfth and subsequent 
lines are the patch indexes of the excluded boundaries. 

B.4 funSd.iunl 

The main input namelist hie, funSd.nml, is described in detail below, with de- 
faults listed before the descriptions. The namelist hie contains a large number 
of input variables. In general, it is not necessary to specify them all because 
they have suitable default values. Only those variables that are different from 
the defaults need to be specihed. An overview of tasks and their associated 
namelists are listed below. 

The project name and grid information: 

(^project (B.4.1) 

&raw_grid (B.4. 2) 

&force_moment_integ_properties (B.4. 3) 

&grid_transform (B.4. 4) 

&body_transform (B.4. 5) 

The equation set and reference conditions: 

&governing_equations (B.4. 6) 

&reference_physical_properties (B.4. 7) 

& noninert ial ^reference Tr ame ( B . 4 . 8 ) 

The inviscid flux discretization: 

&inviscid _hux_method (B.4. 9) 

Turbulence model: 

& t urbulent _dihusion uno dels ( B . 4 . 1 0 ) 

&spalart (B.4. 11) 

&gammaretsst (B.4. 12) 

Number of and size of time steps or steady iterations: 

&codejrun_control (B.4. 13) 

&nonlinear_solver .parameters (B.4. 14) 
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Linear relaxation controls: 

&linear .solver .parameters (B.4.15) 

Boundary conditions and transition: 

&boundary .conditions (B.4.16) 

&two_d_trans (B.4.17) 

&three.d.trans (B.4.18) 

Flowfield initialization: 

&flow jnitialization (B.4.19) 

Force tracking and visualization: 

&component .parameters (B.4.20) 
&time.avg.params (B.4.21) 

&global (B.4.22) 

&volnme_ontpnt .variables (B.4.23) 
&bonndary.ontpnt. variables (B.4.24) 
&sampling.ontpnt. variables (B.4.25) 
&sampling.parameters (B.4.26) 

&slice.data (B.4.27) 

Overset grid systems and rotorcraft simulation: 

&overset.data (B.4.28) 

&rotor.data (B.4.29) 

Grid adaptation: 

&adapt.metric.constrnction (B.4.30) 

&adapt .mechanics (B.4.31) 

Design optimization cost functions: 

&massond.ontpnt (B.4.32) 

&sonic.boom (B.4.33) 

&sboom (B.4.34) 

&eqnivalent.area (B.4.35) 
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&press_boxJunction (B.4.36) 
&pstagJunction (B.4.37) 

Other: 

&speciaLparameters (B.4.38) 
&vortex_generator (B.4.39) 
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B.4.1 &;project 


This namelist allows the user to specify the rootname of the project, which 
forms the majority of input and output hlenames. 

feproject 

project_rootname = ' def ault_project ' 

/ 


project_rootname = ’ default.project ’ 

The project rootname is the root for the grid, restart, and visualization 
hies. The manual refers to it as [project_rootname] . The Mef ault_project ' 
can be replaced with any hlename allowed by the hie system. 
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B.4.2 &raw grid 

This namelist specifies details of the grid format. 


&raw_grid 
grid_f ormat 
data_f ormat 
twod_mode 
swap_yz_axes 

f ieldview_coordinate_precision 

patch_lumping 

ignore_euler_number 

/ 


' vgrid' 

' default ' 
. false . 

. false . 

' double ' 

' none ' 

. false . 


grid_f ormat = ’vgrid’ 

This specifies the grid file format. See section 4 for the details on these 
formats. The currently supported values are: 

'fast’ for FAST .fgrid/.mapbc files. 

' vgrid’ for single- and multi-segmented VGRID .cogsg/.bc/.mapbc files. 

'fun2d’ for Fun 2D. faces files. 

' af lr3 ’ for AFLR3 formatted, unformatted, or C-binary/Fortran-stream 
. ugrid / . r8 . ugrid / . b8 . ugrid / . mapb c files, 

' f elisa’ for Felisa grid files. 

' f ieldview’ for FieldView formatted or unformatted .fvgridTmt/.fvgridmnf/.mapbc 
files. 

data_f ormat = ’default’ 

This provides the encoding of the grid file. A particular grid_f ormat 
may only support a subset of encodings. Fun 3D will stop with an error 
message if the data_format is inconsistent with the grid_format. The 
’ default ’ value is changed to an admissible value based on grid_f ormat 
as noted next to each value, 

'ascii’ ASCII text grid file. It is the default for ’felisa’ and ’fun2d’ 
grids. 

'unformatted’ Fortran unformatted grid file. It is the default for 
’fast’, ’vgrid’, and ’f ieldview’ grids. 

' stream’ C-binary/Fortran-stream grid file. It is the default for ’ af lr3 ’ 
grids. 

' stream64’ 64 bit integer C-binary/Fortran-stream grid file. 
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twod_mode = .false. 


Turns on two-dimensional mode for a single layer prism or hex grid. If 
grid_format = ’fun2d’, twodnnode is automatically .true.. 

swap_yz_axes = .false. 

When .true., this swaps the y- and z-axes for the grid. This option can 
be used to rotate the grid so the z-axes is in the Fun 3D convention for 
angle of attack and lift. 

f ieldview_coordinate_precision = 'double' 

This specihes floating point precision of reals for FieldView meshes only, 
'double' for double precision coordinates. 

' single' for single precision coordinates. 

patch_lumping = 'none' 

This enables boundary patch lumping. It combines the grid patches into 
fewer patches to ease the bookkeeping of patch groups, but will effect all 
features that reference boundary patch numbers (e.g., feboundary .conditions). 
The .mapbc hies for any of the supported grid formats may contain an 
optional third column of data, which specihes a family name. The ex- 
ception is the VGRID. mapbc hie, where the family name is mandatory 
and appears in the sixth column. If family names are not present in the 
.mapbc hie, patch.lumping can not be family. 

' none ' for no patch lumping. 

' be ' for physical boundary condition lumping. 

' family' for family name lumping 

ignore_euler_number = .false. 

This will permit the use of grids with a failing Euler number check. See 
section C.7 for a description of the Euler number and its implications. 
Ignoring the Euler number check is not recommended. 
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B.4.3 &force moment integ properties 


Reference lengths and area are defined in this namelist to scale aerodynamic 
force and moment data. 

&f orce_moment_integ_properties 
area_ref erence = 1.0 
x_moment_length = 1.0 
y_moment_length = 1.0 
x_moment_ center = 0.0 
y_moment_ center = 0.0 
z_moment_center = 0.0 

/ 

area_ref erence = 1.0 

This area is used for non-dimensionalization of forces and moments, spec- 
ihed in grid units squared. For a semi-span model, use half of the full 
conhguration reference area. 

xanoment_length = 1.0 

This length in x-direction is used to nondimensionalize moments about 
y (pitching moment), specihed in grid units. 

yanoment_length = 1.0 

This length in ?/-direction is used to nondimensionalize moments about 
X (rolling moment) and z (yawing moment), specihed in grid units. 

xanoment_center = 0.0 

This specihes the x-coordinate location of moment center, in grid units. 
yanoment_center = 0.0 

This specihes the y-coordinate location of moment center, in grid units. 
zanoment_center = 0.0 

This specihes the z-coordinate location of moment center, in grid units. 
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B.4.4 &grid transform 

This namelist defines a constant grid translation and rotation that is applied 
before the start of the fiow solution. For example, original grid may be reori- 
ented to position the geometry at a different angle of attack. 


&gr id_transf orm 


ds 

= 

0.0 




sx 

= 

1.0 




sy 

= 

0.0 




sz 

= 

0.0 




theta 

= 

0.0 




tx 

= 

1.0 




ty 

= 

0.0 




tz 

= 

0.0 




xO 

= 

0.0 




yo 

= 

0.0 




zO 

= 

0.0 




scale 

= 

1.0 




transf orm(l , 1 : 4) 

= 

1.0, 

0.0, 

0.0, 

0.0 

transform(2, 1 :4) 

= 

0.0, 

1.0, 

0.0, 

0.0 

transformO, 1 :4) 

= 

0.0, 

0.0, 

1.0, 

0.0 

transf orm(4, 1 : 4) 

= 

0.0, 

0.0, 

0.0, 

1.0 


/ 

ds = 0.0 

This is the translation distance. 
sx = 1.0 

This is the x-component of a unit vector in the translation direction, 
sy = 0.0 

This is the ?/-component of a unit vector in the translation direction. 
sz = 0.0 

This is the 2;-component of a unit vector in the translation direction. 
theta = 0.0 

This is the rotation angle (in degrees). A positive rotation is applied by 
the right hand rule with the thumb pointing in direction of rotation axis. 

tx = 1.0 

This is the x-component of the rotation axis unit vector, 
ty = 0.0 

This is the ^/-component of the rotation axis unit vector. 
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tz = 0.0 

This is the 2 ;-component of the rotation axis unit vector. 
xO = 0.0 

This is the x-coordinate of the rotation origin. 
yO = 0.0 

This is the ^/-coordinate of the rotation origin. 
zO = 0.0 

This is the ;^-coordinate of the rotation origin. 
scale = 1.0 

This a scale factor applied to all coordinate values. 

transformCl , 1 :4) = 1.0, 0.0, 0.0, 0.0 

This is a 4x4 transform matrix (see for example [26]). 
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B.4.5 &body transform 

This namelist defines a constant body translation and rotation that is applied 
before the start of the fiow solution. For example, original body may be 
reoriented to position the geometry at a different effective angle of attack. 
After repositioning the body, the mesh is deformed once to reflect the new 
position of the body, before beginning the solution. 

&body_transf orm 
n_bodies 
nbndry ( : ) 
boundary_list ( : ) 
ds(:) 
sx( : ) 
sy(:) 
sz( : ) 
thetaC : ) 
tx( : ) 
ty(:) 
tz( : ) 
x0(:) 
y0(:) 
z0( : ) 

transf orm(l , 1:4,1) 
transform(2, 1:4,1) 
transformO, 1:4,1) 
transf orm(4, 1:4,1) 

/ 

n_bodies = 0 

This is the number of bodies that are to be repositioned at the start of 

the computation. 

nbndry ( : ) =0 

This is the number of boundary patches listed for a given body. 

boundary_list ( : ) = ’’ 

This is a list of boundary patch numbers for a given body. Commas and 

dashes can be used to specify ranges, i.e., ’1,2, 5-7’ . 

ds(:) = 0.0 

This is the translation distance. 

sx(:) = 1.0 

This is the r-component of a unit vector in the translation direction. 


= 0 

= 0 

_ I I 


= 

o 

o 




= 

o 

1 




= 

o 

o 




= 

o 

o 




= 

o 

o 




= 

o 

1 




= 

o 

o 




= 

o 

o 




= 

o 

o 




= 

o 

o 




= 

o 

o 




= 

o 

1 

0.0, 

0.0, 

O 

o 

= 

o 

o 

1.0, 

0.0, 

o 

o 

= 

o 

o 

0.0, 

1.0, 

o 

o 

= 

o 

o 

0.0, 

0.0, 

1.0 
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sy(:) = 0.0 

This is the y-component of a unit vector in the translation direction. 


sz(:) = 0.0 

This is the ;^-component of a unit vector in the translation direction. 
theta(:) = 0.0 

This is the rotation angle (in degrees). A positive rotation is applied by 
the right hand rule with the thumb pointing in direction of rotation axis. 

tx(:) = 1.0 

This is the x-component of the rotation axis unit vector. 
ty(:) = 0.0 

This is the ^/-component of the rotation axis unit vector. 
tz(:) = 0.0 

This is the 2 ;-component of the rotation axis unit vector. 
x0(:) = 0.0 

This is the x-coordinate of the rotation origin. 
y0(:) = 0.0 

This is the ^/-coordinate of the rotation origin. 
z0(:) = 0.0 

This is the ;^-coordinate of the rotation origin, 
transformd , 1 :4, 1) = 1.0, 0.0, 0.0, 0.0 
This is a 4x4 transform matrix (see for example [26]). 
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B.4.6 &;governing equations 


This namelist specifies the equation set that describes underlying physics of 
the problem. 

&governing_equations 
eqn_type 

artif icial_compress 
viscous_terms 
chemical_kinetics 
thermal_energy_model 
prandtlnumber_molecular 
schmidt_number 
gas_radiation 
rad_use_impl_lines 
multi_component_dif f 
cpiv_min_f actor 
augment_kinetics_limiting = 
implicit_rate_limiting 

/ 

eqn_type = ’compressible 
This specifies the set of governing equations to be solved. 

' compressible ’ for compressible, calorically perfect gas. See section 2.1 
for equations and nondimensionalization. 

'incompressible’ for incompressible, calorically perfect gas. [27] See 
section 2.2 for equations and nondimensionalization. The incompress- 
ible solution is affected by the choice of artif icial_compress, see the 
description of this parameter for details. 

'generic’ for multispecies, reacting gas simulations. See section 2.3 
for nondimensionalization. The tdata input file is required. Fun3D is 
usually distributed with the ’ generic’ option disabled. If it is required, 
see section 1.4 for information on obtaining the version of Fun3D with 
this capability. 

artif icial_compress = 15.0 

This is the artificial compressibility factor, /3, which is only used by the 
eqn.type = ’incompressible’. This parameter must be in the range 
of (100,1). See Anderson, Rausch, and Bonhaus [27] for details. The 
sensitivity of the solution to this parameter will decrease with mesh 
refinement, so consider a refined grid if an unacceptable amount of sen- 
sitivity is experienced. A high sensitivity to this parameter can also 
indicate that the problem is actually compressible and the user is en- 
couraged to check the incompressible solution by performing a low Mach 
compressible simulation. 


' compressible ' 
15.0 

' turbulent ' 
'finite-rate ' 

' non-equilib ' 

0.72 

- 1 . 

'off 
.false . 

.false . 

0.0001 
.false . 

. true . 
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viscous_terms = ’turbulent' 

This describes the modeling of the viscosity term in the governing equa- 
tions. 

' inviscid’ no viscosity, for inviscid flow. 

' laminar’ apply laminar viscosity, to model laminar flow. 

' turbulent ’ include laminar viscosity and model turbulent flow with a 
&turbulent_dif fusionunodels. 

chemical_kinetics = ’finite-rate’ 

This describes the chemical kinetics, only used when eqn.type = ’ generic ’ . 
'frozen’ for frozen chemical compositions. 

'finite-rate’ for hnite-rate reacting gases. 
thermal_energy_model = ’non-equilib’ 

This describes the thermal energy model, only used when eqn.type = 

’ generic ’ . 

'frozen’ for frozen chemical compositions. 

'non-equilib’ for non-equilibrium gases, 
prandtlnumberunolecular = 0.72 

This is the molecular Prandtl number. It must be greater than zero, 
schmidt .number = -1. 

This is the Schmidt number used in the generic gas path. If the user 
wants to override the default path of computing a variable Schmidt num- 
ber from collision cross sections then use this parameter to specify the 
constant Schmidt number. 

gas_radiation = ’off’ 

This controls flow held radiation coupling. When active, this option will 
compute radiation source terms and surface heat huxes after the hrst 
time step. Radiation source terms are not further updated during the 
rest of the time steps. Radiation source terms are not stored in the 
restart hie, so they need to be recalculated when restarting simulations 
that include how held radiation. Only for eqn.type = ’generic’ . 

'off’ no radiation calculations. 

'uncoupled’ will use the KARA program to compute radiative surface 
heat huxes, but radiation source terms would not be included in the 
how-held governing equations. 

'coupled’ will include radiation source terms in the governing equa- 
tions, with the divergence of the radiative hux being computed by the 


121 



KARA program. Requires rad_use_impl_lines = .true., only valid if 
all of the domain nodes are included in one and only one line as defined 
by the implicit lines hie. 

rad_use_impl_lines = .false. 

For gas .radiation, the mesh nodes in the lines of sight are read from the 
implicit lines hie. Conpled radiation must use this option. For nnconpled 
radiation, the lines of sight can either be read from the implicit lines hie 
when .true., or the lines of sight will be generated dnring the FUN3D 
rnn when .false. Only for eqn.type = ' generic F 

multi_component_dif f = .false. 

When .true., engage mnlti-component dihnsion using snb-iteration of 
Stefan-Maxwell Eqnations as described by Sntton and Gnoho. [28] Oth- 
erwise, use binary dihusion with mass fraction averaged correction to 
force snm of dihusion hux to eqnal zero. Only for eqn.type = ' generic F 

cpivunin.f actor = 0.0001 

This variable sets the minimnm valne of the vibrational-electronic heat 
capacity as a fraction of the translational-rotational heat capacity for 
each species i. In some cases, ramping this valne np to 0.01 can help 
snppress nndershoot of vibrational temperatnre npstream of a strong 
shock. The vibrational-electronic heat capacity must be positive for 
stability. Only for eqn.type = ’ generic F 

augment_kinetics_limiting = .false. 

When .true., augment chemical kinetic source term limiting. Only for 
eqn.type = ’ generic F 

implicit_rate_limiting = .true. 

When .true., limit chemical rates if extrema exist in formulation Only 
for eqn.type = ' generic F 
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B.4.7 Preference physical properties 


This namelist is used to specify reference conditions and nominal freestream 
flow conditions in a user-deflned unit system. It is also used to convert between 
grid units and flow solver units. 


&ref erence_physical_properties 


dim_ input _type 

= 

' nondimensional 

gridlength_conversion 

= 

1.0 

mach_number 

= 

0.0 

reynolds_number 

= 

0.0 

velocity 

= 

0.0 

density 

= 

0.0 

temperature 

= 

273.0 

temperature_units 

= 

' Kelvin ' 

angle_of _attack 

= 

0.0 

angle_of _yaw 

= 

0.0 


/ 


dim_input_type = ' nondimens ional ’ 

This is the system of measurement for the reference conditions. Cur- 
rently, it must be ’ dimensional-SI ’ for eqn_type = 'generic' and 
' nondimensional ' otherwise. This input is intended for future expan- 
sion. The temperature is always input as a dimensional quantity. 

'nondimensional' requires machmumber and reynoldsmumber to be 
deflned. 

'dimensional-SI' requires dimensional velocity and density to be 
deflned. 

gridlength_conversion = 1.0 

For dim_input_type = 'dimensional-SI', this is the conversion fac- 
tor to scale the grid and it should be set to meters per grid unit. It 
is used for providing heat flux in proper units and other tasks. For 
dim_input_type = 'nondimensional', this should be set to 1.0, be- 
cause the grid is already in nondimensional grid units. 

mach_number = 0.0 

This is the reference Mach number deflned as velocity/speed-of-sound. It 
is only allowed for dim_input_type = 'nondimensional' and eqn_type 
= ' compressible' . It must be set to a positive value. 

reynolds_number =0.0 

This is the reference Reynolds number, per one unit of the grid. Not 
correctly accounting for the unit of the grid has been a point of confusion 
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in the past. For example, when the grid units are feet, Reynolds number 
should be specified per foot. This input is only used if dim_input_type = 
’ nondimensional ' and is ignored by eqn_type = ’generic'. It must 
be set to a positive value. 

velocity = 0.0 

This is the reference velocity, in m/s. Only used for dim_input_type = 
’ dimensional-SI ’ and eqn_type = ’generic’. 

density = 0.0 

This is the reference density, in kg/m^. Only used for dim_input_type 
= ’dimensional-SI’ and eqn.type = ’generic’. 

temperature = 273.0 

This is the reference temperature, in units of temperature_units. 
temperaturemnits = ’Kelvin’ 

The units used to specify temperature. 

'Kelvin’ for SI units. 

' Rankine ’ for the English system. 
angle_of ^attack = 0.0 

This is the freestream angle of attack in degrees. 
angle_of_yaw = 0.0 

This is the freestream angle of yaw (side-slip) in degrees. 
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B.4.8 &;noninertial reference frame 


FUN3D can perform simulations in noninertial reference frame rotating at a 
constant rate, The noninertial reference frame simulation can be run as a 
steady state problem if the freestream velocity crossed with the rotation vector 
is zero, Uoo X = 0. In a practical sense, freestream velocity should be zero 
or parallel to the axis of rotation. Using a standard inertial reference frame 
requires the same problem to be run as an unsteady simulation at a larger 
computational cost. Typical uses would be the simulation of an isolated rotor 
in hover (without forward motion) or an aircraft performing a steady-state 
pitching maneuver or constant roll about the wind axis. 


&noninertial_ref erence frame 
noninertial 
rotation_center_x = 
rotation_center_y = 
rotation_center_z = 
rotation_rate_x 
rotation_rate_y 
rotation_rate_z 

/ 

noninertial = .false. 

When .true., use a noninertial reference frame. The default is the inertial 
reference frame. 

rotation_center_x = 0.0 

This is the x of the steady rotation rate center point. 
rotation_center_y = 0.0 

This is the y of the steady rotation rate center point. 
rotation_center_z = 0.0 

This is the z of the steady rotation rate center point. 
rotation_rate_x = 0.0 

This is the steady noninertial rotation rate (nondimensional) about the 
rotation center x-axis. For eqn.type = Compressible’, the nondi- 
mensional rate is a; = a;*-; — — , where uj* is the dimensional rota- 

^ ref^ref 

tion rate about the rotation center x-axis, in rad/sec. For eqn.type = 
’ incompressible’ , the nondimensional rate is a; = ^ — ; see also 

section 2. 


. false . 
0.0 
0.0 
0.0 
0.0 
0.0 
0.0 
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rotation_rate_y = 0.0 

This is the steady noninertial rotation rate (nondimensional) about the 
rotation center ?/-axis. For eqn_type = ’compressible', the nondi- 
mensional rate is a; = — , where oj* is the dimensional rota- 

^ ref^ref 

tion rate about the rotation center ?/-axis, in rad/sec. For eqn_type = 
’ incompressible’ , the nondimensional rate is a; = — ; see also 

section 2. 

rotation_rate_z = 0.0 

This is the steady noninertial rotation rate (nondimensional) about the 
rotation center z-axis. For eqn.type = ’compressible’, the nondi- 
mensional rate is a; = — , where uj* is the dimensional rota- 

tion rate about the rotation center 2 ;-axis, in rad/sec. For eqn.type = 

L* 

’ incompressible’ , the nondimensional rate is a; = ^ — ; see also 

^ ref^ref 

section 2. 
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B.4.9 &inviscid flux method 


This namelist controls the construction of the inviscid fluxes and flux Jaco- 
bians. 


&inviscid_f lux_method 
f lux_construction 
f lux_construction_lhs 
kappa_umuscl 
f lux_limiter 

f reeze_limiter_iteration = 

f irst_order_iterations 

mult idm_opt ion 

f ixed_direction 

recalc_dir_freq 

adptv_entropy_f ix 

rhs_u_eigenvalue_coef 

lhs_u_eigenvalue_coef 

rhs_a_eigenvalue_coef 

lhs_a_eigenvalue_coef 

entropy_fix 

re_min_vswch 

re_max_vswch 

pole_gradient 


' roe ' 

' vanleer ' 
- 1.0 
' none ' 

-1 

0 

1 

. true . 

1 

. false . 

0. 

0 . 

0 . 

0. 

. false . 
50 . 

500 . 

. false . 


f lux.construction = 'roe' 

This specihes the inviscid flux residual construction method. 

' roe ' for Roe flux difference splitting. 

'vanleer' for van Leer flux vector splitting. 

'hllc' forHLLC. 

'aufs' forAUFS. 

'Idfss' for LDFSS. 

'dldfss' for dissipative LDFSS. 

'aldfss' for LDFSS with an adaptive entropy hx. 

'roe_ec' for entropy-consistent Roe scheme. 

' stvd' for Yee’s symmetric total variation diminishing scheme. 
' stvdanodif ied' for a modihed version of STVD. 

'multidm' for Gnoffo’s multidimensional scheme. 
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f lux_construction_lhs = ’vanleer’ 

This specifies the inviscid fiux Jacobian construction method. A ’ consistent ’ 
method yields the best asymptotic iterative convergence rate of the non- 
linear residual, but a more diffusive fiux may stabilize a poorly converging 
or diverging linear system iterative scheme. 

'consistent’ for a consistent linearization with the residual construc- 
tion method. 

'vanleer’ for Van Leer. 

' roe ’ for Roe linearization. 

'hllc’ for HLLC. 

'aufs’ forAUFS. 

'Idfss’ for LDFSS. 

kappammuscl = -1.0 

Controls the amount of upwinding in the unstructured-grid MUSCL re- 
construction scheme. The default will adjust kappa.umuscl internally 
to 0.5 for 3D mixed-element grids or 0.0 for all other grid types. 0.0 is 
the upwind-biased (Fromm) discretization, 1.0 is the (unstable) central- 
difference discretization, and the range [0,1] is a blend of the two. 

f luxAimiter = ’none’ 

This selects the fiux limiter. The limiters that begin with the letter h, 

’ barth ’ , and ’ venkat ’ are stencil-based limiters (they apply a limiter 
to each edge in a node’s the reconstruction stencil and store the most 
restrictive edge limiter value at the node). Other limiters are evaluated 
in a strictly edge-based manner. The h-series of limiters automatically 
turns on a heuristic pressure based limiter that is used to augment the 
selected fiux limiter. [29] The node-based limiters can be frozen with 
the f reeze_limiter_iteration namelist variable to possibly improve 
“ringing” nonlinear iterative convergence. The adjoint solver is only 
compatible with a frozen limiter. For hypersonic flows computed us- 
ing the calorically perfect gas path, the hvanleer or hvanalbada fiux 
limiters are recommended. 

' none ’ for no limiter. 

'barth’ for the Barth limiter. 

' venkat ’ for the Venkatakrishnan [30] limiter. This limiter is dimen- 
sional and should be scaled if the grid is not normalized to a characteristic 
length of your model. The --smooth_limiter_coef f command line op- 
tion should be set to a reciprocal of a characteristic length, i.e., l/(Mean 
Aerodynamic Chord). 
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' hminmod ' for the stencil-based min- mod limiter augmented with a heuris- 
tic pressure limiter. 

'hvanleer’ for the stencil-based van Leer limiter augmented with a 
heuristic pressure limiter. 

'hvanalbada’ for the stencil-based van Albada limiter augmented with 
a heuristic pressure limiter. 

' hvenkat ' for the Venkatakrishnan limiter augmented with a heuristic 
pressure limiter. 

'minmod' for the min-mod limiter. 

'vanleer' for the van Leer limiter. 

'vanleer_gg’ for van Leer limiter that also turns on Green-Gauss gra- 
dients for inviscid reconstruction. 

'vanalbada' for the van Albada limiter. 
freeze_limiter_iteration = -1 

The node-based limiters can be frozen by setting f reeze_limiter_iteration 
to zero or an iteration number. A negative value does not freeze the lim- 
iter. Zero is used to retain the limiter held contained in the restart 
hie. Freezing can possibly improve “ringing” nonlinear iterative conver- 
gence. [30] If a unrealizable reconstruction (negative density or pressure) 
is encountered the limiter held will be locally updated at the node ex- 
periencing the problematic reconstruction. The adjoint solver is only 
compatible with a frozen limiter. 

f irst_order_iterations = 0 

This is the number of iterations to use hrst-order spatial accuracy prior 
to using second-order spatial accuracy. If second-order spatial accuracy 
in not required, set this to a value larger than the number of steps. 

This option is useful for starting difficult supersonic how simulations. 

For time accurate cases (time_accuracy not equal to ’steady'), this 
is the number of hrst-order accurate sub-iterations to run for each time 
step. 

multidm_option = 1 

This controls the multidm reconstruction weighting. 

' 1 ’ virtual node averaging. 

' 2 ’ weighted average of edges. 
f ixed_direction = .true. 

This specihes the use of Gartesian directions in multdm reconstruction. 
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recalc_dir_freq = 1 

This sets the frequency of direction recalculation in the multidm scheme. 
adptv_entropy_f ix = .false. 

This activates the adaptive entropy £x for Roe’s scheme. 
rhs_u_eigenvalue_coef = 0. 

This is the contact /shear eigenvalue smoothing coefficient for the adap- 
tive entropy fix and the roe residual. 

lhs_u_eigenvalue_coef = 0. 

This is the contact /shear eigenvalue smoothing coefficient for the adap- 
tive entropy fix and the roe Jacobian. 

rhs_a_eigenvalue_coef = 0. 

This is the acoustic eigenvalue smoothing coefficient for the adaptive 
entropy fix and the roe residual. 

lhs_a_eigenvalue_coef = 0. 

This is the acoustic eigenvalue smoothing coefficient for the adaptive 
entropy fix and the roe Jacobian. 

entropy _fix = .false. 

This activates the entropy fix for the stvd flux. 
re_min_vswch = 50. 

For the stvd flux, eigenvalue limiting is tnrned off below this cell Reynolds 
nnmber. 

re_max_vswch = 500. 

For the stvd flux, eigenvalue limiting is fnlly engaged above this cell 
Reynolds number. 

pole_gradient = .false. 

If true, use limiting form of continnity equation across pole in association 
with symmetry_l_strong, symmetry _2_strong, or symmetry _3_strong. 
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B.4.10 &;turbulent diffusion models 

When viscous.terms = Wurbulent’, this namelist is used to set the form 
of the turbulence model. 


&turbulent_dif fusion_models 
turbulence_model 
turb_model 
turb_intensity 
turb_viscosity_ratio 
reynolds_stress_model 
turb_compress_model 
turb_conductivity_model = 
prandtlnumber_turbulent = 
schmidtnumber_turbulent = 
wall_function 


' sa' 

' deprecated-use-turbulence_model ' 
0.001 
0.001 
' linear ' 

'off 

'off 

0. 9 

1 . 

'none ' 


/ 


turbulenceunodel = ’sa’ 

This selects the form of the turbulence model. The naming convention 
of http://turbmodels.larc.nasa.gov/ is used for the models described 
on the website. 

' sa’ for Spalart-Allmaras model. [31] See the fespalart namelist in sec- 
tion B.4.11 for additional controls. 

'sa-catris’ for Spalart-Allmaras Catris-Aupoix model. [32] 

' des ’ for Spalart-Allmaras based DES model. [33] See the fespalart 
namelist in section B.4.11 for additional controls. Not available for 
eqn_type= ’ generic ’ . 

' sa-neg’ for Spalart-Allmaras model with negative turbulence variable 
provisions. [34] Not available for eqn_type= ’ generic ’ . 

'des-neg’ for Spalart-Allmaras based DES model with negative turbu- 
lence variable provisions. [33,34] Not available for eqn_type=’ generic’ . 

'menter-ssf option is no longer valid, use sst or sst-v 

' bsl ’ Menter Baseline Two-Equation Model. [35] 

' sst’ Menter SST Two-Equation Model with strain source term. [35] 

'sst-v’ Menter SST Two-Equation Model with vorticity source term. 
[36] Not available for eqn_type= ’ generic ’ . 

'wilcoxl988’ Wilcox (1988) k-omega Two-Equation Model. [37] Not 
available for eqn_type= ’ generic ’ . 

' wilcoxl988-v’ Wilcox (1988) k-omega Two-Equation Model with vor- 
ticity source term. [37] Not available for eqn_type= ’ generic ’ . 
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'wilcox2006’ Wilcox (2006) k-omega Two-Equation Model. [38] Not 
available for eqn_type= ' generic ’ . 

' wilcox2006-v' Wilcox (2006) k-omega Two-Equation Model with vor- 
ticity source term. [38] Not available for eqn_type= ’ generic ’ . 

'hrles’ for Menter SST-based hybrid- RANS/LES model. [39,40] Does 
not work with eqn_type= ' generic ’ . 

' gamma-ret-sst ' for Langtry and Menter SST transition model. [41] 

See the fegammaretsst namelist in section B.4.12 for additional controls. 

Not available for eqn_type=’ generic ’ . 

'baldwin-lomax’ Baldwin-Lomax algebraic model. Available only for 
eqn_type= ' generic ’ . 

' cebeci-smith' Cebeci-Smith algebraic model. Available only for eqn.type 
generic. 

turbjnodel = ’ deprecated-use-turbulencennodel ' 

This is a deprecated namelist variable for turbulence jiodel. It is in- 
cluded for backwards compatibility with fun3d.nml hies, but may be 
removed in a future version. 

turb.intensity = 0.001 

This sets the freestream turbulence intensity, where k is the tur- 

bulent kinetic energy. Only applies to eqn_type=' generic' . 

turb_viscosity_ratio = 0.001 

This sets the freestream ratio of turbulent viscosity to molecular viscos- 
ity. Only applies to eqn_type= ’ generic ’ . 

reynolds_stress_model = 'linear' 

This controls the mean stress-strain constitutive relation. 

' linear' indicates the use of the linear Boussinesq assumption. 

' qcr ' activates the Quadratic Constitutive Relationship (QCR) of Spalart. 
[42] This non-linear model is not valid for explicit algebraic Reynolds 
stress or full Reynolds stress transport models (e.g., ASM, EASM, RSM 
models). 

turb_compress_model = 'off' 

This controls the turbulence compressibility model. Only applies to 
eqn_type= ' generic ' . 

'off' for no correction. 

'ssz' for SSZ (use with Spalart-Allmaras models). 
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'zeman’ for Zeman (use with k — e models). 

' Wilcox' for Wilcox (use with SST-based models). 

' sarkar' for Sarkar (use with k — e models). 
turb_conductivity_model = 'off' 

This controls whether a turbulence conductivity model is employed. 
Only applies to eqn_type= ’ generic ' . 

' of f ’ to turn off a turbulence conductivity model. 

' on ’ to turn on a turbulence conductivity model. 

prandtlnumber_turbulent = 0.9 

This is the turbulent Prandtl number. 

schmidtnumber_turbulent = 1. 

This is the turbulent Schmidt number. Only applies to eqn_type=’ generic ’ . 

wall_function = 'none' 

This is the name of the wall function model. 

'none' integrates to the the wall (no wall function). 

'dir' utilizes the wall function of Knopp, Alrutz, and Schwamborn. 

[43] Can be used with turbulence_model = 'sa', turbulencennodel 
= ' sst ' , or their variations. 
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B.4.11 &;spalart 

This namelist is used to modify details of the SA and SA based DES turbulence 
models. 


fespalart 

turbinf 

dacles_mariani 


= 3.0 


= .false. 
= .false. 
= .false. 
= .false. 
= 0.975 


sarc 

ddes 


ddes_modl 

cddes 


/ 


turbinf = 3.0 

This is the freestream turbulence value for the SA model. 
daclesunariani = .false. 

This activates the Dacles-Mariani [44, 45] rotation correction (denoted 
SA-R by http://turbmodels.larc.nasa.gov/). 

sarc = .false. 

This activates the rotation/curvature correction [46] (denoted SA-RC by 
http : //turbmodels. larc.nasa.gov/). 

ddes = .false. 

This changes the turbulence jnodel=Mes ’ into Delayed DES [47] (DDES) 
ddesunodl = .false. 

This changes the turbulence_model='des’ into Modihed Delayed DES 
[48] (MDDES). It also requires ddes = .true. This option should be used 
with caution. Most experience with this model is for large separated 
flows encountered in wake regions of bluff bodies, such as cylinders and 
landing gears. Further validation is required for other situations. There 
is sensitivity to the parameter cddes. 

cddes = 0.975 

This is Cmdd in [48]. It used with the ddesnnodl = .true. 
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B.4.12 &gammaretsst 


This namelist modifies the details of the turbulence jnodel = ' gamma-ret-sst ’ 
transition turbulence model of Langtry and Menter. [41] Correctly setting the 
freestream levels of turbulence is key to the transition location of this model. 
Ideally, freestream turbulence levels are measured in an experiment. 

fegammaretsst 

set_k_inf _w_turb_intsty_percnt = -1.0 
set_w_inf _w_eddyviscosity = -1.0 

/ 


set_k_inf _w_turb_intsty_percnt = -1.0 

This is the freestream turbulence level as a percentage. A negative value 
uses the default /Coo = 9 x 10“®. A positive value will set k^c = 1-5 x 
(0.01 X M X set_k_inf _w_turb_intsty_percnt)^. 

set_w_inf _w_eddyviscosity = -1.0 

This is the freestream eddy viscosity as the ratio between turbulent eddy 
viscosity to laminar viscosity. A negative value uses the default Woc = 
10“®. A positive value will set cUoo = A;oo/set_w_inf _w_eddyviscosity. 
If not available, a value in the range of 0.05 to 5 is commonly used, but 
the appropriate value is case specific. 
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B.4.13 &code run control 

This namelist controls the length of the simulation. Restart options, Jacobian 
update strategy, and angle of attack continuation can also be specihed. 

&code_run_control 


steps 

= 

500 

stopping_tolerance 

= 

l.e-15 

duration_limit_in_minutes 

= 

-1.0 

no_restart 

= 

.false 

restart_write_f req 

= 

250 

restart_read 

= 

' on ' 

smart _j update 

= 

. true . 

j acobian_eval_f req 

= 

0 

jupdate_startup_steps 

= 

10 

jupdate_amut_max_change 

= 

0.20 

jupdate_cf l_inv_change 

= 

5.0 

df duc3_ j acobians 

= 

.false 

alpha_sweep 

= 

.false 

cycle_increment 

= 

50 

alpha_increment 

= 

0.25 

alpha_max 

= 

180.0 

alpha_min 

= 

-180.0 

alpha_switchbacks 

= 

0 

serialize_part it loner 

= 

.false 

write_steady_restart 

= 

.false 

steps_per_period 

= 

1 


steps = 500 

This is the number of time steps or steady iterations to perform, 
stopping.tolerance = l.e-15 

This instructs the solver to terminate before all steps are complete when 
the root mean square (RMS) of every equation (continuity, energy, etc.) 
is less than this tolerance. 
duration_limit_in_minutes = -1.0 

This is the maximum run duration limit in minutes (a negative value 
is unlimited). This limit can terminate the solver before all steps are 
complete, which may be helpful if the solver is run as a batch system job 
with a time limit. Additional time is required to complete the current 
iteration and write restart hie. So, allow an extra time margin for code 
shutdown. MPI required. 

no_restart = .false. 

When this is .true., no restart checkpoint hie is written. 
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restart_write_f req = 250 

The restart checkpoint and convergence history hies will be written to 
disk every restart_write_freq time steps. 

restart _read = 'on' 

This dehnes the solution at the hrst time step. 

' on ' to initialize the simulation with a solution read from the restart 
hie. The current convergence history will be concatenated with the prior 
solution history. 

' on_nohistorykept ' to initialize the simulation with a solution read 
from the restart hie. The previous history (e.g., residuals, forces, mo- 
ments) will be discarded. 

' of f ' for no restart hie read. The solution will be initialized as freestream 
or as specihed in the &f low_initialization namelist. 

smart _j update = .true. 

This option allows the code to automatically adjust the Jacobian update 
frequency based on residual reduction. 

jacobian_eval_f req = 0 

This is the frequency of Jacobian evaluation based on time steps. It 
should be set to zero when smart_jupdate = .true. 

jupdate_startup_steps = 10 

The Jacobians are evaluated at every time step for the hrst jupdate_startup_steps, 
which aids robustness during initial start transients. 

jupdate_amut_max_change = 0.20 

For turbulent how, the Jacobians are refreshed when maximum eddy 
viscosity changes by this amount from the maximum eddy viscosity cor- 
responding to the last Jacobian evaluation. 

jupdate_cf l_inv_change = 5.0 

The Jacobians are refreshed when the time term associated with ch of 
the adaptive strategy and the time term of the Jacobian evaluation diher 
by this amount. 

dfduc3_jacobians = .false. 

This option only ahects eqn.type = 'incompressible'. When .true., 
approximate Jacobians are computed that may improve the convergence 
of some cases. 
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alpha_sweep = .false. 

This option activates a procedure to adjust angle.of .attack during a 
simulation. It can be used to calculate a drag polar in a single execution 
or explore a hysteresis loop. It is controlled by the following options. 

cycle.increment = 50 

When alpha_sweep=.true, 

cycle.increment <0 increments angle.of .attack after residuals have 
reached the stopping.tolerance. 

cycle.increment > 0 is the number of iterations between increments 
to alpha. 

cycle.increment = 0 is an inadmissible value, 
alpha.increment = 0.25 

When alpha.sweep=.true., increment angle.of .attack by these many 
degrees at a point controlled by cycle.increment. 

alphannax = 180.0 

When alpha.sweep=.true., this is the maximum value of angle.of .attack, 
alphaanin = -180.0 

When alpha_sweep=.true., this is the minimum value of angle.of .attack, 
alpha.switchbacks = 0 

When alpha.sweep=.true., this is the number of directional changes in 
the angle.of .attack sweep. When alpha.switchbacks > 0, alpha.increment 
changed in sign after reaching alphaanax or alphannin. This allows ex- 
ploration of hysteresis loops. 

serialize.partitioner = .false. 

The default calls ParMETIS with the partitioning graph distributed 
equally to all processors. When .true., the partitioning graph is gath- 
ered to the master node and the serial version of METIS distributed with 
ParMETIS is called. This can improve parallel load balance for small 
ratios of grid size to the number of partitions. This option can increase 
memory usage or grid processing time. 

write.steady .restart = .false. 

When write.steady .restart=. true., and running a time-accurate sim- 
ulation (itime\=0), this will cause a steady-state restart hie to be writ- 
ten, rather than an unsteady restart hie. This steady-state restart hie al- 
lows the steady-state solver to be used on subsequent executions. Warn- 
ing, solution time history will be discarded. 
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steps_per_period = 1 

This is the number of time steps-per-period of a periodic simulation. 
The value is currently only used in the output of periodic FWH data. 


139 



B.4.14 ^nonlinear solver parameters 

This namelist defines the temporal accuracy of the solution advancement 
scheme. The subiterations and time step size of time accurate simulations 
can also be specified. The ramping of the pseudo time advancement CFL 
number is also set. Density and pressure floors on the update and relation 
factors are available. 


&nonlinear_solver_parameters 
time_accuracy 
time_step_nondim 
subiterations 
temporal_err_control 
temporal_err_f loor 
schedule_iteration(l : 2) 
schedule_cf 1 (1 : 2) 
schedule_cf Iturbd : 2) 
f _allow_minimuni_m 
invis_relax_f actor 
vise relax factor 


' steady ' 

0.0 

0 

. false . 

0.1 
1, 50 

200 . 0 , 200.0 
50.0, 50.0 
0.01 
1.0 
1.0 


time.accuracy = ’steady' 

This defines the temporal scheme. 

' steady’ for steady state calculations. This is a local time step pseudo- 
time advancement scheme that is not time accurate. 

' Istorder’ is a first-order backward differencing scheme (backward Eu- 
ler) for time-accurate temporal time integration. 

' 2ndorder ’ is a second-order backward differencing scheme (BDF2 in 
[49]) for time-accurate temporal time integration. 

' 2ndorderOPT ’ is an optimized second-order backward differencing (BDF2opt 
in [50]) for time-accurate temporal time integration. This scheme is 
second-order accurate in time but has an order-of-magnitude lower lead- 
ing coefficient than standard BDF2. 

' Srdorder ’ is a third-order backward differencing scheme (BDF3 in 
[49]) for time-accurate temporal integration. 

' 4thorderMEBDF4’ is a fourth-order modified extended backward differ- 
encing scheme (MEBDF4 in [49]) for time-accurate temporal integration. 

' 4thorderESDIRK4’ is a fourth-order explicit, singly diagonally implicit 
Runge-Kutta (ESDIRK4 in [49]) for time-accurate temporal integration. 
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time_step_nondim = 0.0 


This is the nondimensional time step for time accurate simulations. 
It is ignored when time_accuracy = ’ steady h The nondimension- 
alization of this parameter depends on eqn_type. When eqn_type = 

’ compressible' , it is where a^e/ is the reference speed of sound, 

and L is unit 1 of the grid. When eqn.type = 'incompressible' or 
'generic', it is where u^e/ is the reference velocity. See sec- 

tion 2.4 for more details and guidance on appropriate values. 

subiterations = 0 

Number of subiterations applied to solve the implicit time integration. 
It is ignored when time_accuracy = 'steady'. A constant CFL time 
step is used in each subiteration. By the end of a convergent subiteration 
process the pseudo time term drops out, giving the correct temporal 
discretization. 

temporal_err_control = .false. 

This governs whether the specified number of subiterations are run for 
each time step (.false.), or, if the temporal error is monitored and the 
subiterations are stopped when a specified tolerance is reached (.true.). 
It is ignored when time .accuracy = ' steady' . 

temporal.err .floor = 0.1 

This sets the tolerance for which time-accurate subiterations are stopped. 
The tolerance is given as a multiplicative factor of the flow residuals 
(mean and turbulence). It is ignored when time.accuracy = ' steady' . 

schedule.iterationCl : 2) = 1, 50 

These are the iteration or subiteration numbers at which CFL numbers 
are specihed. When time.accuracy = ' steady' , this controls the CFL 
number of the pseudo-time terms over iterations. When running time- 
accurately, this controls the CFL number of the pseudo-time terms of the 
linear system over subiterations. The parameter schedule.iteration(l) 
must be one, because it defines the starting CFL number at the first 
iteration or subiteration. The actual CFL number is determined by 
a linear ramp from schedule.cf 1 (1) at schedule.iteration(l) to 
schedule.cf 1 (2) at schedule.iteration(2) . The CFL number is held 
constant at schedule.cf 1 (2) after schedule_iteration(2) . 

schedule.cfl(l:2) = 200.0, 200.0 

This controls the ramping and hnal CFL number of the meanflow equa- 
tions. See the description for schedule.iteration. 
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schedule.cf Iturbd : 2) = 50.0, 50.0 

This controls the ramping and hnal CFL number of the turbulence model 
equations. See the description for schedule_cf 1 in schedule_iteration. 

f _allowmiinimuiimii = 0.01 

This limits the solution update to prevent pressure and density from 
dropping below this fraction of their freestream values. Applied to 
eqn.type = ’compressible' only. 

invis_relax_f actor = 1.0 

This is the relaxation factor of inviscid terms. It scales the nonlinear 
update of the inviscid terms by this fraction and is only used for eqn_type 
= ’generic’. 

visc_relax_f actor = 1.0 

This is the relaxation factor of viscous terms. It scales the nonlinear 
update of the viscous terms by this fraction and is only used for eqn_type 
= ’generic’. 


142 



B.4.15 &;linear solver parameters 

The Fun 3D solution process involves constructing a linearization of the resid- 
ual with appropriate time terms and then solving this linear system to compute 
the solution update. This namelist controls the solution process of this linear 
system. The linearization is grouped in to the meanflow equations and the 
turbulence model equations. 

&linear_solver_parameters 
meanf low_sweeps = 15 
turbulence_sweeps = 10 
linear_projection = .false. 
line_ implicit = 'off 

/ 

meanf low.sweeps = 15 

This is the number of the linear system red-black relaxations at each 
steady iteration or time step of the meanflow equations when there is no 
turbulence model or a loosely coupled turbulence model. For eqn_type 
= ’ generic’ or fully coupled meanflow and turbulence relaxation, this 
refers to all equations (meanflow and turbulence). 

turbulence_sweeps = 10 

This is the number of the linear system red-black relaxations at each 
steady iteration or time step of the turbulence equations, when the tur- 
bulence equations are loosely coupled. It has no effect for fully coupled 
meanflow and turbulence relaxation or a simulation without a turbulence 
model. 

linear .projection = .false. 

This options uses a Krylov projection method generalized conjugate gra- 
dient (GCR) to stabilize and improve convergence of linear system. This 
will execute multiple sets of red-black relaxation to form the CGR search 
directions, until a convergence criteria is met. 

line.implicit = ’off’ 

This option selects the relaxation scheme. 

'off’ uses point implicit relaxation. 

' on ’ uses line implicit relaxation where lines are defined and point relax- 
ation elsewhere. The line implicit feature requires construction of these 
lines prior to running Fun 3D. The lines are stored in the a hie named 
[project_rootname] .lines.fmt, see section 4.4 for a description. The 
af IrS.line.extraction utility is distributed with Fun 3D to generate 
these lines. 
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B.4.16 ^boundary conditions 


This namelist provides auxiliary information to the boundary conditions. Re- 
fer to section 3 for the definition of boundary numbers and other information. 


&boundary_conditions 

total_pressure_ratio ( : ) 

total_temperature_ratio ( : ) 

subsonic_inf low_velocity ( : ) 

alpha_bc( : ) 

beta_bc( : ) 

thetal ( : ) 

theta2 ( : ) 

theta3( : ) 

pt_amplitude ( : ) 

pt_frequency ( : ) 

pt_phase( : ) 

tt_amplitude ( : ) 

tt_frequency ( : ) 

tt_phase( : ) 

ampl ( : ) 

freqC : ) 

phase ( : ) 

random ( : ) 

ramp_constant ( : ) 

start_time ( : ) 

durationC : ) 

surge_amplitude ( : ) 

pressure_relaxation( : ) 

engine_ref erence_length 

inlet_symmetry 

npr_set 

static_pressure_ratio ( : ) 
inlet_solution_method( : ) 
mach_bc( : ) 
massf low( : ) 
grid_units 
q_set ( : , 1 : 5) 
q_set_ramp( : ) 
prof ile_type ( : ) 
patch_center ( : ,1:3) 
patch_scale ( : ) 
prof ile_rho_coef ( : ,0:6) 
prof ile_u_coef ( : ,0:6) 
prof ile_p_coef ( : ,0:6) 
prof ile_coef ( : ,1:3) 


= 1.0 
= 1.0 
= ' normal ' 

= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= .false. 

= 1.0 
= 0.0 
= 0.0 
= 0.0 
= 1.0 
= 1.0 
= 1.0 
= 0.0 
= 1.0 
= 'mach' 

= 0.0 
= 0.0 
= 'nondim' 

= 0.0 
= 0 

= ' radial_polynomial ' 
= 0.0 
= 1.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
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wall_velocity ( : ,1:3) 
rotation_center ( : , 1 : 3) 
rotation_vector ( : , 1 : 3) 
rotation_rate ( : ) 
unorm_bc ( : ) 
wall_temperature ( : ) 
wall_temp_f lag( : ) 
wall_radeq_f lag( : ) 
wall_emissivity ( : ) 
wall_emissivity_b( : ) 
wall_emissivity_c ( : ) 
wall_emissivity_d( : ) 
wall_temp_relax( : ) 
wall_catalysis_model ( : ) 
catalytic_eff iciency_o( : ) 
catalytic_ef f iciency_n( : ) 
ablation_option_niap( : ) 
ablation_recession 
ablation_recession_freq 
start_recession 
bprime_f lag_map( : ) 
compute_mdot_initial_map( : ) 
f req_mdot_map ( : ) 
f req_wall_map ( : ) 
uncoupled_ablation_flag_niap( : ) 
wall_blowing_model ( : ) 
virgin_density_wall ( : ) 
char_density_wall ( : ) 
CHONSi_frac_char_map( : ,1) 
CHONSi_frac_pyrolysis_map( : , 1) 
h_ablation_map( : , : ) 
mdot_pressure_map( : , : ) 
t_sublimation_map( : , : ) 
plenum_tO( : ) 
plenum_pO( : ) 
plenum_id( : ) 
f ixed_in_id( : ) 
f ixed_in_rho ( : ) 
f ixed_in_uvw ( : ,1:3) 
f ixed_in_t ( : ) 
f ixed_in_tv( : ) 
f ixed_in_turb( : ,1:7) 
specif ied_transition( : ) 
impose_pressure_gradient 
pressure_gradient ( : ) 


0.0 

0.0 

0.0 

0.0 

0.0 

1.0 

. false . 

. false . 

0.8 

0. 

0. 

0. 

0.001 

' super-catalytic ' 

0. 

0. 

0 

. false . 

3000 

0 

1 

1 

5000 

50 

0 

'none ' 

1 . 

1 . 

1 . 

1 . 

0. 

0. 

0. 

1000. 

1000 . 

0 

0 

0. 

0. 

0. 

0. 

0. 

. false . 

. false . 

0.0 
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solidity ( : ) 


0.0 

0.0 


porous_coef f icient ( : ) 
x_ const ant _boundary( : ) 
y_constant_boundary ( : ) 
z_constant_boundary ( : ) 
tol_const_ coord 


. false . 
. false . 
. false . 
l.Oe-6 


/ 


total_pressure_ratio( : ) = 1.0 

This is the ratio of plenum total pressure to reference pressure used by 
7011 boundary condition. Inflow Mach number must be less than one. 

total_temperature_ratio( : ) = 1.0 

This is the ratio of plenum total temperature to reference temperature 
used by 7011 boundary condition. Inflow Mach number must be less 
than one. 

subsonic.inf low_velocity ( : ) = ’normal' 

This sets the direction of the inflow velocity. 

' normal ’ for inflow normal to each element face in the patch 

'alpha, beta’ the angle of the inflow is specihed by alpha.bc and 
beta_bc as shown in Fig. 4. 

'interior’ the angle of the inflow is specified by the Euler angles 
thetal, theta2, and thetaS as shown in Fig. B5. 

'offset’ the angle of normal inflow to the patch boundary is rotated 
by the Euler angles thetal, theta2, and thetaS as shown in Fig. B5. 

alpha_bc(:) = 0.0 

When subsonic_inf low_velocity = ’ alpha, beta’ , this is the angle 
of attack in radians for 7011 boundary condition inflow. 

beta_bc(:) = 0.0 

When subsonic_inf low_velocity = ’ alpha, beta’ , this is the angle 
of sideslip in radians for 7011 boundary condition inflow. 

thetalC:) = 0.0 

When subsonic_inf low_velocity = ’interior’ or ’offset’, this is 
the Euler angle 6 in radians for 7011 boundary condition inflow. 

theta2(:) = 0.0 

When subsonic_inf low_velocity = ’interior’ or ’offset’, this is 
the Euler angle 0 in radians for 7011 boundary condition inflow. 
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theta3(:) = 0.0 

When subsonic_inf low_velocity = ’interior^ or 'offset’, this is 
the Euler angle ip in radians for 7011 boundary condition inflow. 

pt_conplitude ( : ) = 0.0 

For use with the 7011 boundary condition, this sets the amplitude of 
pulsed total pressure. ampl*sin(freq*simulation_time+phase*pi/180). 

pt_frequency ( : ) = 0.0 

For use with the 7011 boundary condition, this sets the frequency of 
pulsed total pressure, see ampl. 

pt_phase(:) = 0.0 

For use with the 7011 boundary condition, this sets a phase shift (in 
degrees) of the inflow total pressure values, see ampl. 

tt_amplitude ( : ) = 0.0 

For use with the 7011 boundary condition, this sets the amplitude of 
pulsed total temperature conditions. 

tt_frequency ( : ) = 0.0 

For use with the 7103 boundary condition, this sets the frequency of 
pulsed total temperature, see ampl. 

tt_phase(:) = 0.0 

For use with the 7011 boundary condition, this sets a phase shift (in 
degrees) of the inflow total temperature, see ampl. 

arnpK:) = 0.0 

For use with the 7103 boundary condition, this sets the amplitude of 
pulsed inflow conditions. Only the velocity is varied using the equation 
[u,v,w\ = ampl*sin(f req*simulation_time+phase*pi/180). 

freq(:) = 0.0 

For use with the 7103 boundary condition, this sets the frequency of 
pulsed inflow velocity values, see ampl. 

phase(:) = 0.0 

For use with the 7103 boundary condition, this sets a phase shift (in 
degrees) of the inflow velocity values, see ampl. 
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random(:) = .false. 

For use with the 7103 boundary condition, this creates random fluctua- 
tions in in the magnitude of the supersonic inflow conditions in the range 
[0,ampl] when .true.. 

ramp^constant ( : ) = 1.0 

For use with 7104 boundary condition, this ramps the velocity magnitude 
of supersonic inflow conditions with the exponential expression, (1 — 
exp(— simulation_time/ramp_constant)). 

start_time( : ) = 0.0 

For use with the 5060 boundary condition, this is the start time, in terms 
of Fun3D simulation.time, of a delta function change to the subsonic 
outflow static pressure ratio. 

durationC:) = 0.0 

For use with the 5060 boundary condition, this sets the duration of the 
delta function change in units of Fun3D time, see simulation_time. 

surge_amplitude ( : ) = 0.0 

For use with the 5060 boundary condition, this sets the transient increase 
in the value of the outflow static pressure ratio as a percentage of the 
base line value. For example, a 2 percent transient applied to block 5 is 
input as surge_amplitude(5) = 2.0. 

pressure_relaxation( : ) = 1.0 

For use with the 5051 boundary condition, this weights the user specified 
back pressure with the solution pressure, p.applied = pressure_relaxation 
* static_pressure_ratio -|- ( 1 - pressure_relaxation ) * pressure_internal 

engine_ref erence.length = 1.0 

Use this factor to scale the non-dimensional time in the engine simulation 
package. 

inlet_symmetry = 1.0 

Use this factor to scale the area and massflow of an inlet face For example, 
set to 2.0 to double an inlet face on a symmetry plane or set to 1.0 for 
a full span model. 

npr.set = 0.0 

This sets the nozzle pressure ratio for nozzle component performance. 
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static_pressure_ratio( : ) = 1.0 

This is the ratio of specihed boundary static pressure to reference pres- 
sure used by the 7012 and 5051 boundary conditions. Outflow Mach 
number must be less than one. 

inlet_solutionjnethod( : ) = ’mach’ 

This is the solution method for 7031 be. 

'mach' adjusts back pressure to attain a Mach number mach_bc. Do not 
use for a face that has boundary layer ingestion; use ^ pressure ' in that 
situation. 

' massf lux’ adjusts back pressure to attain a specihed mass hux massf low. 
' pressure ’ adjusts back pressure to attain a specihed mass hux massf low. 
mach_bc(:) =0.0 

This is Mach number on boundary face used by 5052 and 7031 boundary 
conditions. Outhow Mach number must be less than one. 

massflowC:) = 0.0 

This is masshow through boundary face in units of grid unit squared 
used by 7031 and 7036 boundary conditions. It is nondimensionalized 
according to (poo^oo) for eqn_type = ’compressible’. 

grid.units = ’nondim’ 

This converts a user specihed dimensional masshow to units of mesh unit 
squared. If masshow is input in units of mesh units squared, grid_units 
is not required. 

'nondim’ for nondimensional input 

' m ’ for meters 

' cm ’ for centimeters 

' mm ’ for millimeters 

'feet’ for feet 

' inches ’ for inches 

q_set ( : , 1 : 5) = 0.0 

This sets the primitive variables on boundary face used by boundary 
conditions 7100 and 7105. 

q_set_ramp( : ) = 0 

When this is greater than zero, primitive variables on boundary face are 
ramped from zero to q_set over these iterations, for boundary conditions 
7100 and 7105. 
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prof ile_type ( : ) = ' radial.polynomial ' 

This switches between inflow profiles, 

' radial.polynomial ' defines a radial polynomial about patch.center 

of size patch_scale with prof ile_rho_coef , prof ile_u_coef , and prof ile_p_coef . 

' power.law' defines a power-law velocity profile function with prof ile.coef . 

patch_center ( : , 1 : 3) = 0.0 

This is the center of a 7101 be. 

patch_scale( : ) = 1.0 

This scales the radius of a 7101 be. 

prof ile_rho_coef ( : , 0 : 6) = 0.0 

This is the radius polynomial coefficients of density for 7101 be. 
prof ile_u_coef ( : , 0 : 6) = 0.0 

This is the radius polynomial coefficients of u for 7101 be. 
prof ile_p_coef ( : , 0 : 6) = 0.0 

This is the radius polynomial coefficients of pressure for 7101 be. 
prof ile_coef ( : , 1 : 3) = 0.0 

These three coefficients are wind speed reference, reference height, and 
power law exponent, 

prof ile_coef ( : , 1) *(z/prof ile.coef ( : , 2) ) **prof ile_coef ( : , 3) 
wall_velocity( : , 1 : 3) = 0.0 

This is the 4000 solid wall specified translational velocity. It should be 
tangent to the boundary to ensure a well-posed problem. 

rotation_center( : , 1 :3) = 0.0 

This is the 4000 solid wall specified rotational velocity center point, see 
rotation.vector and rotation_rate. 

rotation_vector( : , 1 :3) = 0.0 

This is the 4000 solid wall specified rotational vector, see rotation_center 
and rotation_rate. Should be unit length. 

rotation_rate( : ) = 0.0 

This is the 4000 solid wall specified rotational rate in reference speed of 
sound per grid unit (eqn_type = 'compressible') or reference speed 
per grid unit (eqn_type = ' incompressible' ) (a; = uj *— — — or a; = 

^ ref-^ref 

L* 

. ), see rotation.center, rotation.vector, and section 2. 

V ref -l^ref ’ ’ 
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unorm_bc(:) = 0.0 

This is the specihed velocity in the boundary normal direction, for 4000 
solid walls. 

wall_temperature( : ) = 1.0 

This is the ratio of wall temperature to reference temperature for eqn.type 
= ' compressible ’ or the wall temperature in degrees Kelvin for eqn.type 
= ' generic h If set to -1, then the wall temperature is computed so 
that there is zero heat flux, i.e., adiabatic. The wall_temp_f lag must 
be set to .true, for this boundary condition to take effect. 

wall_temp_f lag( : ) = .false. 

This must be .true, when specifying the wall temperature via the namelist 

variable wall_temperature. The default .false, sets 

for eqn_type = 'compressible’, see Anderson and Bonhaus [2]. 

wall_radeq_f lag( : ) = .false. 

Compute the wall temperature via the Stefan-Boltzmann Law. The ra- 
diative equilibrium wall temperature is computed from the heating rate 
(Iwaii using qyjaii = ^(^T^adeq where the surface emissivity e is entered as 
wall_emissivity and a is the Stefan-Boltzmann constant. 

wall.emissivity ( : ) = 0.8 

This is 6o, where emissivity is specihed as a function of wall temperature 
with the expression e = Cq -l- T(e;, -|- T(ec + Te^)). The other coefficients 
are entered via the following three variables. 

wall_emissivity_b( : ) = 0. 

This is Cf, in the above equation. 

wall_emissivity_c ( : ) = 0. 

This is 6c in the above equation. 

wall_emissivity_d( : ) = 0. 

This is 6d in the above equation. 

wall_temp_relax( : ) = 0.001 

This is the relaxation factor t] used for wall_radeq_f lag wall tempera- 
ture boundary condition. The wall temperature is updated as = 
T^l^ + r]*{Tradeq-T°'^) 

wall_catalysisjnodel( : ) = ’super-catalytic’ 

This dehnes the catalytic efficiency of the wall to promote recombination 
of atoms to molecules. Allowable options are: 
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'super-catalytic' Forces the mass fraction of species at the wall to 
equal the mass fractions specihed for the free stream in the tdata hie. 

' fully-catalytic ' Specihes a catalytic efficiency of 1 thereby forcing 
homogeneous recombination of atoms diffusing to the wall. 

' non-catalytic ’ Specihes a zero mole fraction gradient at the wall - 
signifying zero catalytic efficiency. 

' equilibrium-catalytic' Computes the equilibrium chemical compo- 
sition of species at the wall temperature and pressure. 

' constant-catalytic' Catalytic efficiency is user specihed constants 

' Stewart-RCG' Reaction cured glass from Stewart 

'Zoby-RCG' Reaction cured glass from Zoby 

'Scott-RCG' Reaction cured glass from Scott 

'CSiC' Experimental CSiC from JSC for X-38 

'RCC-LVP' Stewart NASA TM 112206 

'CCAT-ACC' Shuttle RCC from Stewart NASA TM 112206 

'CSiC-SNECMA' Derived from Stewart RCC 

catalytic.eff iciency_o ( : ) = 0. 

This is the fraction of dihusion hux of atomic oxygen striking wall 
that is converted to molecular oxygen, when wall_catalysis unodel = 
' constant-catalytic ' . 

catalytic.eff iciency_n( : ) = 0. 

This is the fraction of dihusion hux of atomic nitrogen striking wall 
that is converted to molecular nitrogen, when wall_catalysisunodel = 
' constant-catalytic ' . 

ablation_option_map( : ) = 0 

This is an integer that specihes whether the pyrolysis ablation rate and 
wall temperature are computed in addition to the char ablation rate. 
This option only ahects cases with bprime_f lagunap equal to 0 or 1. 

'0' The pyrolysis ablation rate and wall temperature are computed, in 
addition to the char ablation rate, assuming steady-state ablation. 

' 1 ' The pyrolysis ablation rate and wall temperature are held constant 
(they are set to the values present in ablation.f rom_laura.m) while the 
char ablation rate is computed. 
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ablation_recession = .false. 

This flags triggers the surface deformation and mesh movement through 
aeroelastic deformation. Note: this flags only applies to the internal 
Fun3D coupled-ablation mechanism and is not applicable to Fun3d- 
CHAR coupled ablation. Default: .false. 

ablation_recession_freq = 3000 

It is an integer that specifies the frequency of surface recession up- 
date. This flags only works with ablation_recession = .true.. De- 
fault: 3000 

start_recession = 0 

It is an integer that specifies when to start applying recession for surface 
deformation. Default: 0 

bprime_f lagunapC : ) = 1 

This is an integer defining if the b-prime approach is applied. Applicable 
only for blowing model equil_char_quasi_steady = 0. 

' 0 ' Do not use bprime approach, and instead use a rigorous diffusion 
model. This option is consistent with the ’’Fully-Coupled” approach 
defined in Ref. [2]. 

‘ 1 ’ Use b-prime approach. This option is consistent with the ’’Partially- 
Coupled” approach defined in Ref. [2]. 

' 2 ' Hold the ablation rate and wall temperature constant from the 
restart file, while applying the rigorous diffusion model (thus, the surface 
energy balance and char equilibrium constraint are not satisfied). This 
option is sometimes useful when transitioning from a bprime flag = 1 
computation to a bprime flag = 0 computation. 

compute_mdot_initial_map( : ) = 1 

This is an integer defining if the ablation rates are computed before the 
first flowfleld iteration. 

' 0 ' Applies the ablation rates and wall temperatures present in the 
ablation.f rom_laura.m file. 

' 1 ' Computes the ablation rates and wall temperatures before the first 
flowfleld iteration. 

freq_mdot_map( : ) = 5000 

For bprime_f lagjnap = 1, this is an integer defining frequency of up- 
dating ablation rates and wall temperature. 
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freq_wall_map( : ) = 50 

For bprime_flag = 1, this is an integer defining frequency of update 
to ablation wall boundary conditions. For bprime_flag = 0, an inte- 
ger defining frequency of update to the surface energy balance solution, 
which defines the wall temperature. 

uncoupled_ablation_flag_map( : ) = 0 

This is an integer defining if an uncoupled ablation analysis is applied. 
The uncoupled ablation option is included to provide a baseline solution 
for the coupled ablation analysis. 

' 0 ' Do not apply an uncoupled ablation analysis. 

' 1 ' Apply an uncoupled ablation analysis to a converged non-ablating 
fiowfield. 

wall_blowingjnodel( : ) = ’none' 

This is the blowing or ablation model. 

' none ’ No wall blowing 

' specified’ blowing rate is user specified function of pressure (see also 
mdot.press) 

'porous_chamber’ Special options for simulation of buoyancy driven 
flow in pressurized rig for BNNT production 

' quasi .steady ’ Compute ablation rate as function of surface energy 
balance and equilibrium catalytic be 

' equil_char_quasi_steady ’ Include equilibrium char approximation 
'FIAT’ Couple to material response code FIAT (not active) 
virgin.density.wall ( : ) = 1. 

This is the density (kg/m^) of thermal protection system ablator in virgin 
state (prior to heating level sufficient to cause any reactions). 

char_density_wall ( : ) = 1. 

This is the density (kg/m^) of remaining char in ablator after binding 
resins have pyrolized. 

CH0NSi_f rac.char jnapC : , 1) = 1. 

See definition below for CHONSi.f rac.pyrolysis unap 

CHONSi_frac_pyrolysisjnap( : , 1) = 1. 

These arrays set elemental mass fraction (second index) of C, H, O, N, 
Si, Fe, Mg, Na, B species for char and pyrolysis gas. The fractions in 
each array should sum to 1. 
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h_ablation_map( : , : ) = 0. 

This is a vector of extent 3 used to compute the heat of ablation in MJ /kg 
for quasi steady blowing option as h_ablation_0(l) + (h_ablation_0(2) 

) log pw + (h_ablation_0(3)) (log pw) where pw is the local 
pressure, in atmospheres. 

mdot_pressure_map( : , : ) = 0. 

This is a vector of extent 2 is used to set the blowing or suction dis- 
tribution dehned as mdot_pressure_0(l) + (mdot_pressure_0(2))*p/ 
(rho.inf *V_inf **2) where p is the local pressure, rho_inf is the refer- 
ence density, and V_inf is the reference velocity. Positive value produces 
blowing distribution, while negative value produces suction distribution. 

t_sublimation_map( : , : ) = 0. 

This is a vector of extent 3 used to compute the sublimation temperature 
in degrees Kelvin for quasi steady blowing option as t_sublimation_0(l) 

+ (t_sublimation_0(2) ) log pw + (t_sublimation_0(3) ) (log pw) 
**2 where pw is the local pressure, in atmospheres. 

plenum_t0( : ) = 1000. 

For use with the 7021 boundary condition, this is the total plenum tem- 
perature in Kelvin. 

plenum_p0(:) = 1000. 

For use with the 7021 boundary condition. The total plenum pressure in 
N/m^ (Pascals) feeding this boundary. 

plenum_id(:) = 0 

For use with the 7021 boundary condition (one or more rcs.jet plenum 
bcs), the jet plenum contains this species set from the hie tdata. For 
example, if an RCS jet is bring H 2 and O 2 into an air stream, the tdata 
ble may look like: 

One Temperature 
N 
0 

N2 0.76 
02 0.24 
NO 

H2 0.5 
02 0.5 
OH 
H 
0 
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In this case, if the boundary to the plenum is surface number 5 then 
plenum_id(5)=2, the second grouping of species in the tdata hie. The 
numbers following the species name dehne the mass fraction of that 
species at the inhow boundary. The sum of the mass fraction in each 
group must equal one. Species groups are separated by blank lines and 
multiple RCS jets may be dehned in this manner. 

f ixed_in_id( : ) = 0 

For use with the 70XX boundary condition (one or more supersonic 
inhow bcs) the supersonic inhow boundary condition contains the species 
set in the same way as the plenum_id for the rcs.jet plenum boundary 
condition described above 

f ixed_in_rho( : ) = 0. 

For use with the 70XX boundary condition (one or more supersonic 
inhow bcs) the dimensional inhow mixture density in kg/m**3 

f ixed_in_uvw( : , 1 : 3) = 0. 

For use with the 70XX boundary condition (one or more supersonic in- 
how bcs) the dimensional inhow Cartesian velocity components in m/sec 

f ixed_in_t ( : ) = 0. 

For use with the 70XX boundary condition (one or more supersonic 
inhow bcs) the dimensional inhow translational rotational temperature 
in Kelvin 

f ixed_in_tv( : ) = 0. 

For use with the 70XX boundary condition (one or more supersonic 
inhow bcs) the dimensional inhow vibrational-electronic temperature in 
Kelvin 

f ixed_in_turb( : , 1 : 7) = 0. 

For use with the 70XX boundary condition (one or more supersonic 
inhow bcs) This is for the turbulence models for a one-equation model 
this is the ratio of the inhow eddy viscosity to the inhow molecular 
viscosity, for a two-equation model this is: the inhow turbulence intensity 
and the ratio of the inhow eddy viscosity to the inhow molecular viscosity 
Full Reynolds stress models are not currently supported 

specif ied_transition( : ) = .false. 

When .true., a turbulent transition point will be imposed on the solu- 
tion. 
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impose_pressure_gradient = .false. 

When .true., a global pressure gradient in the direction of pressure.gradient 
will be imposed as a source term to the residual. 

pressure_gradient ( : ) = 0.0 

The nondimensional pressure gradient in Cartesian coordinates, imposed 
when impose_pressure_gradient = .true. 

solidityC:) = 0.0 

This is the percent solidity to be applied to the passive porosity boundary 
conditions. 

porous.coef f icient ( : ) = 0.0 

This is the Darcy law equation coefficient. 

x. const ant .boundary (: ) = .false. 

This specihes that a boundary is an x constant face for mesh movement, 
constraining motion the to be tangent to face. Set automatically for 
x-symmetry boundaries. 

y. const ant .boundary (: ) = .false. 

This specihes that a boundary is an y constant face for mesh movement, 
constraining motion the to be tangent to face. Set automatically for 
y-symmetry boundaries. 

z. constant.boundary ( : ) = .false. 

This specihes that a boundary is an constant face for mesh movement, 
constraining motion the to be tangent to face. Set automatically for 
;^-symmetry boundaries. 

tol.const.coord = l.Oe-6 

This is the tolerance for verifying that a boundary surface is a planar 
boundary for mesh movement by restricting the minimum and maximum 
value in the “constant” direction. 
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B.4.17 &two d trans 

This namelist is used to specify a 2D transition location. If the airfoil is split 
into upper and lower patches, the transition location can be specihed indepen- 
dently on each patch. If there is only a single patch, it can be split with a z 
value to designate the upper and lower airfoil surfaces. This transition specih- 
cation is limited to specifying transition on a single-element conhguration such 
as an airfoil or a flat plate. Only a single transition location is supported for 
multi-element airfoils. Transition is modeled by turning off the turbulent pro- 
duction terms in “laminar” regions of the grid. This option is only valid for the 
perfect gas SA turbulence model. This is the same approach taken in CFL3D 
and NSU3 D.Fun 3D results from this approach for a DLR-F6 transonic cruise 
condition are shown in Lee-Rausch et ah [51] 

&two_d_trans 

turb_transition 
use_2d_values 
upper_patch 
lower_patch 
use_z_value 
z_location 
upper_x_location 
lower_x_location 

/ 

turb_transition = .false. 

This must be .true, to specify laminar regions of flow during a turbulent 
flow simulation. 

use_2d_values = .false. 

This enables 2D transition specihcation. 

upper _patch = 1 

This is the upper patch with specihed transition. 
lower_patch = 1 

This is the lower patch with specihed transition. 
use_z_value = .false. 

This allows a single patch to be split into upper and lower surfaces of an 
airfoil by a z plane. 

z_location = 0.0 

This is the z location to split the airfoil if use_z_value = .true. 


= .false. 
= .false. 
= 1 
= 1 

= .false. 
= 0.0 
= 0.0 
= 0.0 
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upper_x_location = 0.0 

This is the upper surface x transition location. 

lower_x_location = 0.0 

This is the lower surface x transition location. 
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B.4.18 &three d trans 

This namelist is used to specify 3D boundary layer transition locations. The 
command line option — turb.transition is required to activate. If you run 
the flow solver without the — turb.transition, it will default to fully tur- 
bulent even though you have the laminar boundaries dehned. Transition is 
modeled by the turning off the turbulent production terms in “laminar” re- 
gions of the grid. This option is only valid for the perfect gas SA turbulence 
model. This is the same approach taken in CFL3D and NSU3 D.Fun 3D re- 
sults from this approach for a DLR-F6 transonic cruise condition are shown 
in Lee-Rausch et ah [51] 

&three_d_trans 
use_3d_values 
n_transition_group 
transition_group_patches ( : ) 
transition_xl ( : ) 
transition_yl ( : ) 
transition_x2 ( : ) 
transition_y2 ( : ) 

/ 

use_3d_values = .false. 

This turns 3D transition specihcation on. 
n_transition_group = 1 

This is the number of patch groups, limited to 100. 
transition_group_patches ( : ) = ’1’ 

This is the patch indexes for each group. Commas and dashes can be 
used to specify ranges, i.e., ’1,2, 5-7’ . 

transition_xl ( : ) = 0.0 

This is the x value for determining the start of the transition line. 
transition_yl ( : ) = 0.0 

This is the y value for determining the start of the transition line. 
transition_x2( : ) = 0.0 

This is the x value for determining the end of the transition line. 
transition_y2( : ) = 1.0 

This is the y value for determining the end of the transition line. 


= .false. 
= 1 
= ' 1 ' 

= 0.0 
= 0.0 
= 0.0 
= 1.0 
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B.4.19 &flow initialization 

This namelist allows the user to initialize regions of the meanflow solution with 
quantities other than freestream. A maximum of 100 volumes can be dehned. 
The volumes may overlap each other as well as domain boundaries. In the event 
that a grid point is contained in more than one volume, a subsequent volume 
in this hie will supersede the volumes listed before it. Boundary conditions 
supersede the how initialization. 


&flow_ initialization 


number_of _volumes 

= 

0 

type_of_volume( : ) 

= 

' none ' 

center (1 :3, : ) 

= 

0.0 

radius ( : ) 

= 

0.0 

pointl (1 : 3, : ) 

= 

0.0 

point2(l :3, : ) 

= 

0.0 

radius 1 ( : ) 

= 

0.0 

radius2( : ) 

= 

0.0 

rho ( : ) 

= 

1.0 

c(:) 

= 

1.0 

u(:) 

= 

0.0 

v(:) 

= 

0.0 

w( : ) 

= 

0.0 

mass_fraction( : , : ) 

= 

l.e-20 

temperature ( : , : ) 

= 

1000. 


/ 

number_of _volumes = 0 

This is the number of initialization volumes. 

type_of ^volume ( : ) = 'none’ 

This is the type of initialization volume. 

'box’ for a box. The diagonal corners are specihed by point 1 and 
point2. 

' sphere ’ for a sphere. The position and size is specihed by center and 
radius. 

'cylinder’ for a cylinder with size radius. The center axis is dehned 
between pointl and point2. 

' cone ’ for a cone or frustum. The center axis is dehned between pointl 
and point2. Two radii are required, radius 1 at pointl and radius2 
at point2. A frustum is specihed with two nonzero radii. 

centerCl :3, : ) = 0.0 

This is the center of the ’ sphere ’ volume type. 
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radius(:) = 0.0 


This is the radius of the ’sphere' and ’cylinder’ volume types, 
pointld :3, : ) = 0.0 

This is one end of the ’ cone ’ or ’ cylinder’ volume types or one corner 
of a ’box’ volume type. 

point2(l :3, : ) = 0.0 

This is the other end of the ’ cone’ or ’ cylinder’ volume types or the 
opposite corner of a ’box’ volume type. 

radinsl ( : ) = 0.0 

This is the radius at pointl of ’cone’ volume type. 
radius2(:) = 0.0 

This is the radius at point2 of ’cone’ volume type. 
rho(:) = 1.0 

This is the nondimensional density in the volume. 
c(:) = 1.0 

This is the nondimensional speed of sound in the volume. 
u(:) = 0.0 

This is the nondimensional x-component of velocity in the volume. 
v(:) = 0.0 

This is the nondimensional ?/-component of velocity in the volume. 
w(:) = 0.0 

This is the nondimensional ;^-component of velocity in the volume. 
mass_fraction( : , : ) = l.e-20 

This is the species mass fraction array in the volume. The maximum 
number of species is hardwired to 50 in this namelist. All mass fractions 
are initialized to trace values (l.e-20) so it is only necessary to dehne 
non-trace species. 

temperatureC : , : ) = 1000. 

This is the translational-rotational and vibrational electronic tempera- 
ture array in the volume, in units of Kelvin. 
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B.4.20 ^component parameters 


This namelist provides expanded ability to track forces, moments, and mass- 
flows according to user-specified groups of boundary patches that dehne a 
“component.” 

&component_parameters 
number_of _components 
component_ count ( : ) 
component_xmc ( : ) 
component_ymc ( : ) 
component_zmc ( : ) 
component_cref ( : ) 
component_bref ( : ) 
component_sref ( : ) 
component_hinge_sweep ( : ) 
component_hinge_dihedral ( : ) 
component_input ( : ) 
component_name ( : ) 
calculate_cd( : ) 
calculate_thrust_ratio ( : ) 
massf low_component ( : ) 
throat_area( : ) 
npr ( : ) 

allow_f low_through_f orces 

/ 

number_of ^components = 0 
This is the number of components (groups of boundary patches) to track. 
component_count ( : ) =0 

This is the number of boundary patches assigned to a component. If -1 
is given, this number is computed implicitly from component_input. 

component_xmc( : ) = xjnoment_center 

This is x-coordinate of the moment center assigned to a component. The 

default value comes from the force and moment namelist, &f orce_moment_integ_properties 

component_ymc( : ) = y_moment_center 

This is ^/-coordinate of the moment center assigned to a component. The 

default value comes from the force and moment namelist, &f orce_moment_integ_properties 

component_zmc( : ) = z_moment_center 

This is z-coordinate of the moment center assigned to a component. The 

default value comes from the force and moment namelist, &f orce_moment_integ_properties 


= 0 
= 0 

= x_moment_ center 
= y_moment_center 
= z_moment_center 
= x_moment_length 
= y_moment_length 
= ref erence_area 
= 0.0 

= 0.0 

_ I I 

_ I I 

= .false. 

= .false. 

= 0 
= 0.0 
= 0.0 
= .false. 
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component.cref ( : ) = x_moment_length 

This is the x-direction reference length assigned to a component used to 
non-dimensionalize moments about y (pitching moment). The default 
value comes from the force and moment namelist &f orce_moment_integ_properties. 

component.bref ( : ) = y_moment_length 

This is the y-direction reference length assigned to a component used to 
non-dimensionalize moments about x (rolling moment) and (yawing 
moment). The default value comes from the force and moment namelist 
&f orce anoment_integ_properties. 

component.sref ( : ) = ref erence_area 

This is the reference area assigned to a component used to non-dimensionalize 
forces and moments. The default value comes from the force and moment 
namelist &f orce_moment_integ_properties. 

component _hinge_sweep( : ) = 0.0 

This is the hinge sweep angle in degrees assigned to a component used 
to non-dimensionalize moments about y (pitching moment). The default 
value is zero. 

component_hinge_dihedral ( : ) = 0.0 

This is the hinge dihedral angle in degrees assigned to a component used 
to non-dimensionalize moments about x (rolling moment). The default 
value is zero. 

component_input ( : ) = ’ ’ 

This is the list of boundary patches to assigned to a component. Bound- 
ary indexes are separated with commas and dashes can be used to specify 
ranges, i.e., ’1,2, 5-7’. 

componentmcone ( : ) = ’ ’ 

This is the component output hlename, [pro j ect_rootname] _fm_ [componentmame] 
.dat. 

calculate_cd( : ) = .false. 

This will request an ideal mass flow calculation for component n. 
caIculate_thrust_ratio ( : ) = .false. 

This will request a thrust ratio calculation for component n. 
massf low.component ( : ) = 0 

Specihes what component to get the physical mass flow from to calculate 
the ideal thrust. 
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throat_area( : ) = 0.0 

This is the throat area associated with component n. 

npr(:) = 0.0 

This is the set nozzle pressure ratio associated with component n. 
allow_f low_through_f orces = .false. 

Pressure drag and skin friction forces are by default calculated only on 
boundary faces designated as solid surfaces ( viscous or inviscid ). To 
include the pressure and momentum flux forces due to nozzles or in- 
lets allow_f low_through_f orces should be set to .true.. The flow- 
through faces to be tracked should be listed in the component_count 
and component_input lists accordingly. 
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B.4.21 &time avg params 


This namelist controls the bookkeeping of time average and root mean square 
statistics for every point in the domain. Tracking these statistics enables vi- 
sualization of variables like p_tavg, u_trms, etc. See the visualization output 
variable namelists &volume_output_var fables, &boundary_output_variables, 
and &sampling_output_variables for details. When these statistics are tracked, 
the hie [project_rootname] _TAVG.l maintains information across restarts. 
This statistics hie is similar to the [project_rootname] .flow restart hie in 
that is not intended for the user to interact with directly. 


&time_avg_params 

itime_avg = 0 

prior_time_avg = -1 

use_prior_time_avg = 1 
tavg_header_version = 1 

/ 


itime_avg = 0 

This controls collection of temporal statistics. 

' W do not compute time averaging statistics. 

' 1 ' compute time averaging statistics required for visualization. 
prior_time_avg = -1 

This option is deprecated, see use_prior_time_avg. 
use_prior_time_avg = 1 

This controls if a prior execution should contribute to the temporal 
statistics. 

'1' combines the prior statistics stored in [project_rootname] _TAVG.l 
with the statistics of this execution. If [project_rootname] _TAVG.l is 
not available in the current directory, only the statistics from this exe- 
cution will be calculated. 

'0' discards prior statistics. The hie [project_rootname] _TAVG.l will 
be ignored, if it exists. 

tavg_header_version = 1 

This option controls the variables for which statistics are collected. 

' 1 ' for primitive variable averages and root mean squares. 

' 2 ' for primitive variable averages, primitive variable root mean squares, 
and the averages of u’v' ,v’w' , mu_t , vort anag. 
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B.4.22 &;global 


This namelist controls the frequency of visualization output and the logging of 
command line options. It also serves to control some global options otherwise 
set by command-line input 

feglobal 

moving_grid 
grid_motion_only 
grid_motion_and_dci_only 
body_motion_only 
timing 

time_moving_grid 
boundary_animation_freq 
boundary_animation_freq_tavg 
volume_animation_freq 
slice_freq 
record_conunand_lines 
recompute_turb_dist 
turb_dist_update_freq 

/ 

moving_grid = .false. 

This governs whether the grid is moving or stationary 

grid_motion_only = .false. 

This turns off the flow solve during a simulation for which moving.grid = 
.true.. If the simulation involves overset grids, this command overrides 
dci_on_the_f ly and DCI hies are not output. 

grid_motion_and_dci_only = .false. 

This turns off the how solve during a simulation for which moving_grid 
= .true.. If the simulation involves overset grids, this command honors 
dci_on_the_f ly and DCI hies are output if dci_on_the_f ly = .true.. 

body_motion_only = .false. 

This turns oh both the how solve and the linear elasticity solve dur- 
ing a simulation for which moving_grid = .true, and gridunotion = 
’ deform' 

timing = .false. 

This triggers a timing of the execution of various sections of the how 
solver. 


= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= 0 
= 0 
= 0 
= 0 

= .false. 
= .false. 
= 1 
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time_moving_grid = .false. 


This triggers timing of the execution of various sections of the flow solver, 
with emphasis on operations associated with grid motion. The timing 
occurs over larger sections of the code than the timing option. For 
correct timing information, timing and time unoving_grid should not 
be used simultaneously. 

boundary_animation_freq = 0 

This is the visualization output frequency of the domain boundaries. 

Zero is no output, -1 is output at the end of run, and a positive integer 
is periodic output every boundary _animation_freq iterations. See the 
&boundary_output_variables namelist for more details. 

boundary_animation_freq_tavg = 0 

This is the visualization output frequency of time-averaged data on the 
domain boundaries. Zero is no output, -1 is output at the end of run, and 
a positive integer is periodic output every boundary_animation_f req_tavg 
iterations. 

volume_animation_f req = 0 

This is the visualization output frequency of the domain volume. Zero 
is no output, -1 is output at the end of run, and a positive integer is peri- 
odic output every volume_animation_f req iterations. See &volume_output_variables 
namelist for more details. 

slice_freq = 0 

This is the output frequency of boundary slices for visualization and to 
obtain loads. Zero is no output, -1 is output at the end of run, and 
a positive integer is periodic output every slice_freq iterations. See 
&slice_data namelist for more details. 

record_command_lines = .false. 

This creates a hie temp. commands that contains the command line argu- 
ments 

recompute_turb_dist = .false. 

This is a hag that allows for the distance function to be recomputed after 
grid deformation or when overset grids are moved. 

turb_dist_update_freq = 1 

This is the frequency with which the distance function is updated when 
recompute_turb_dist = .true.. 
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B.4.23 &;volume output variables 

This namelist controls volume variable output. Output frequency is controlled 
by volume_animation_f req in the feglobal namelist. The resulting volume- 
data hies have the following naming convention for export_to=' tecplot ' 
output; 

[project_rootname] _part [P] _tec_volume_timestep [T] ( .dat I .pit) if freq > 0 
[project_rootname] _Part [P] _tec_volume( .dat I .pit) if freq < 0 

where P = 1,2,. . . ,nproc (number of processors) and T is the iteration number. 

The hie extension is .dat for ASCII Tecplot™ format and .pit for binary 
Tecplot™ format. Within the hies, a single zone is written, with the zone 
title “time O.OOOOOOOE-l-00 processor 32” where the time value is the integer 
iteration number for steady-state cases, and the current (non-dimensional) 
time for time-dependent cases. 

A request to output an undehned variable will overruled, i.e., turbl will 
be forced to .false regardless of user input when there is no turbulence model 
in the simulation. 


&volume_output_variables 


export_to 

= 

' tecplot 

X 

= 

.true . 

y 

= 

.true . 

z 

= 

.true . 

primitive_variables 

= 

.true . 

rho 

= 

.false . 

u 

= 

.false . 

V 

= 

.false . 

w 

= 

.false . 

P 

= 

.false . 

entropy 

= 

.false . 

mach 

= 

.false . 

temperature 

= 

.false . 

iblank 

= 

.false . 

imesh 

= 

.false . 

vort_mag 

= 

.false . 

vort_x 

= 

.false . 

vort_y 

= 

.false . 

vort_z 

= 

.false . 

q_criterion 

= 

.false . 

div_vel 

= 

.false . 

turbulent _fluctuat ions 

= 

.false . 

uuprime 

= 

.false . 

vvprime 

= 

.false . 

wwprime 

= 

.false . 
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uvprime 

uwprime 

vwprime 

cp 

dp_pinf 

volume 

residuals 

resl 

res2 

res3 

res4 

res5 

res_gcl 

primitive_tavg 

rho_tavg 

u_tavg 

v_tavg 

w_tavg 

P-tavg 

primitive_trms 

rho_trms 

u_trms 

v_trms 

w_trms 

p_trms 

lambdal 

lambda2 

lambdas 

lambdad 

lambdas 

lambdas 

lambda? 

htot 

ttot 

ptot 

etot 

processor_id 

turb_ke 

turb_diss 

mu_t 

turbl 

turb2 

turbS 

turb4 

turbS 


= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
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turb6 

= 

.false 

turb7 

= 

.false 

turresl 

= 

.false 

turres2 

= 

.false 

turresS 

= 

.false 

turres4 

= 

.false 

turresB 

= 

.false 

turres6 

= 

.false 

turres7 

= 

.false 

slen 

= 

.false 

if lagslen 

= 

.false 

hrles_blend 

= 

.false 

re construct ion_limiter_phil 

= 

.false 

re construct ion_limiter_phi2 

= 

.false 

re construct ion_limiter_phi3 

= 

.false 

re construct ion_limiter_phi4 

= 

.false 

re construct ion_limiter_phi5 

= 

.false 

tt 

= 

.false 

tv 

= 

.false 

sonic 

= 

.false 

mixture_mol_weight 

= 

.false 

mixture_density 

= 

.false 

ev 

= 

.false 

rho_i(l :n_species) 

= 

.false 

mu 

= 

.false 

id_12g 

= 

.false 

divided_residuals 

= 

.false 


export.to = 'tecplof 
file format of volume export 

'tecplot' is Tecplot™ format (one file written for each processor) 

' cgns ’ is CGNS format, requires Fun3D to be configured with a CGNS 
library. This format already includes x, y, and z. Set these variables to 
.false, to avoid duplication. 

'fvuns’ is FieldView G-binary (Fortran stream) format. This format 
already includes x, y, and z. Set these variables to .false, to avoid 
duplication. 

' f V ’ is depreciated. Slated for removal, use ’fvuns’ 

'vtk’ is legacy VTK format This format already includes x, y, and z. 
Set these variables to .false, to avoid duplication. 

' CSV’ is comma separated value format 
' sol ’ is INRIA Metrix sol format 
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'tec’ is a single image ASCII Tecplot™ format 

'raw.ascii’ is a single image ASCII space separated format 

'native’ is the most efficient way to export the entire ffow held to disk 
at every time step when the grid is over a billion elements, but requires 
specialized visualization tools to read. 

X = .true. 

X-coordinate 
y = .true. 

Y -coordinate 
z = .true. 

Z-coordinate 

primitive.variables = .true. 

Output primitive variables: rho, u, v, w, and p 
rho = .false. 

Density 
u = .false. 

X-component of velocity 
V = .false. 

X-component of velocity 
w = .false. 

Z-component of velocity 
p = .false. 

Pressure 

entropy = .false. 

Entropy 
mach = .false. 

Mach number 
temperature = .false. 

Temperature 
iblank = .false. 

I-blanking variable (default becomes .true, for overset mesh cases) 
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imesh = .false. 


For overset mesh systems, index of associated component grid where 0 
indicates background grid 

vortJiiag = .false. 

Vorticity magnitude 

vort_x = .false. 

X-component of vorticity 

vort_y = .false. 

X-component of vorticity 

vort_z = .false. 

Z-component of vorticity 

q.criterion = .false. 

Q Criterion, the second invariant of W 

div_vel = .false. 

Velocity divergence 

turbulent_f luctuations = .false. 

Activate all the following XYprime turbulent shear stresses normalized by 
the dehnition of these variables depends on the turbulence model, 
see http://turbmodels.larc.nasa.gov/noteonrunning.html for details 

uuprime = .false. 

Turbulence fluctuation, u'u' 

vvprime = .false. 

Turbulence fluctuation, v'v' 

wwprime = .false. 

Turbulence fluctuation, w'w' 

uvprime = .false. 

Turbulence fluctuation, u'v' 

uwprime = .false. 

Turbulence fluctuation, u'w' 

vwprime = .false. 

Turbulence fluctuation, v'w' 
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cp = .false. 

Pressure coefficient 
dp_pinf = .false. 

Normalized delta pressure (p — Poo)/Poo 

volume = .false. 

Dual-cell volume size 
residuals = .false. 

Activate all resN variables 
resl = .false. 

Residual of equation 1, density 
res2 = .false. 

Residual of equation 2, x-momentum 
res3 = .false. 

Residual of equation 3, ?/-momentum 
res4 = .false. 

Residual of equation 4, 2 :-momentum 
res5 = .false. 

Residual of equation 5, energy 
res.gcl = .false. 

For moving meshes, residual of grid conservation law 
primitive.tavg = .false. 

Output time-averaged primitives (requires &time_avg_params namelist): 
rho_tavg, u_tavg, v_tavg, w_tavg, and p_tavg 

rho.tavg = .false. 

Time- averaged density 

u_tavg = .false. 

Time-averaged x-component of velocity 
v_tavg = .false. 

Time-averaged y-component of velocity 
w_tavg = .false. 

Time-averaged ;^-component of velocity 
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p_tavg = .false. 

Time- averaged pressure 
primitive.trms = .false. 

Output root mean squared primitives (requires &time_avg_params namelist): 
rho.trms, u_trms, v_trms, w_trms, and p_trms 

rho_trms = .false. 

RMS-average of density 

u_trms = .false. 

RMS-average of x-component of velocity 
v_trms = .false. 

RMS-average of y-component of velocity 
w_trms = .false. 

RMS-average of ;^-component of velocity 
p_trms = .false. 

RMS-average of pressure 
lambdal = .false. 

Adjoint Lagrange multiplier for equation 1 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lajnbda2 = .false. 

Adjoint Lagrange multiplier for equation 2 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambdas = .false. 

Adjoint Lagrange multiplier for equation 3 (when rnnning the adjoint, 
the primitive variables are tnrned off, and this is tnrned on) 

lambda4 = .false. 

Adjoint Lagrange mnltiplier for equation 4 (when rnnning the adjoint, 
the primitive variables are tnrned off, and this is tnrned on) 

lambdas = .false. 

Adjoint Lagrange mnltiplier for eqnation 5 (when rnnning the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambdas = .false. 

Adjoint Lagrange multiplier for equation 6 (when rnnning the adjoint, 
the primitive variables are tnrned off, and this is tnrned on) 
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lambda? = .false. 

Adjoint Lagrange multiplier for equation 7 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

htot = .false. 

Total enthalpy per unit volume 
ttot = .false. 

Total temperature 
ptot = .false. 

Total pressure 
etot = .false. 

Total energy per unit volume 
processor.id = .false. 

Processor on which a node resides 
turb_ke = .false. 

Turbulence kinetic energy 
turb_diss = .false. 

Turbulence dissipation rate 
mu_t = .false. 

Turbulent eddy viscosity 
turbl = .false. 

Turbulence variable 1 (model dependent) 
turb2 = .false. 

Turbulence variable 2 (model dependent) 
turb3 = .false. 

Turbulence variable 3 (model dependent) 
turb4 = .false. 

Turbulence variable 4 (model dependent) 
turbS = .false. 

Turbulence variable 5 (model dependent) 
turbS = .false. 

Turbulence variable 6 (model dependent) 
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turb7 = .false. 

Turbulence variable 7 (model dependent) 
turresl = .false. 

Residual of 1st turbulence equation 
turres2 = .false. 

Residual of 2nd turbulence equation 
turresS = .false. 

Residual of 3rd turbulence equation 
turres4 = .false. 

Residual of 4th turbulence equation 
turresS = .false. 

Residual of 5th turbulence equation 
turres6 = .false. 

Residual of 6th turbulence equation 
turres7 = .false. 

Residual of 7th turbulence equation 
slen = .false. 

Length to the nearest solid wall boundary 
iflagslen = .false. 

Turbulence model distance function closest boundary entity, (a negative 
sign indicates the node has been prescribed as laminar) 

hrles_blend = .false. 

HRLES blending function 

reconstruction_limiter_phil = .false. 

(f) for the node-based reconstruction limiters (equation 1) 

reconstruction_limiter_phi2 = .false. 

(f) for the node-based reconstruction limiters (equation 2) 

reconstruction_limiter_phi3 = .false. 

0 for the node-based reconstruction limiters (equation 3) 

reconstruction_limiter_phi4 = .false. 

(j) for the node-based reconstruction limiters (equation 4) 
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reconstruction_limiter_phi5 = .false. 

(j) for the node-based reconstruction limiters (equation 5) 
tt = .false. 

Translational temperature only for eqn_type = 'generic' 
tv = .false. 

Vibrational temperature only for eqn_type = 'generic' 
sonic = .false. 

Frozen speed of sound only for eqn_type = 'generic' 
mixture_mol_weight = .false. 

Mixture molecular weight only for eqn.type = 'generic' 
mixture_density = .false. 

Mixture density only for eqn.type = 'generic' 
ev = .false. 

Vibrational energy only for eqn.type = 'generic' 
rho_i(l :n_species) = .false. 

Species concentration only for eqn.type = 'generic' 
mu = .false. 

Total viscosity 
id_12g = .false. 

Local-to-global node map 
divided_residuals = .false. 

adds a _vol suffix to the residual output variable names and divide by 
volume 
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B.4.24 ^boundary output variables 

This namelist controls the boundary variable output. Output frequency is 
controlled by boundary _animation_freq in the feglobal namelist. By default, 
the output of solution data for all solid surfaces in 3D and on one y-constant 
symmetry plane in 2D is included unless boundary_list is specihed. 

Each time boundary data output is triggered, all output boundaries are 
written to one hie with the following naming convention: 

[project_rootname] _tec_boundary_timestep[T] ( .dat I .pit) if N > 0 
[project_rootname] _tec_boundary ( . dat I .pit) if N < 0 

where T is the iteration number. The hie extension is .dat for ASCII Tec- 
plot™ format and .pit for binary Tecplot™ format. Within the hies, each 
boundary is written as a separate zone. The zones are identihed with the title 
“time O.OOOOOOOE-l-00 boundary 5” where the time value is the integer iter- 
ation number for steady-state cases, and the current (non-dimensional) time 
for time-dependent cases. 

By default, output is in the inertial reference frame. For moving body 
problems, the &observer_motion namelist can be used to change the visual- 
ization reference system to a body reference system or a reference system with 
arbitrary motion. 

A request to output an undehned variable will overruled, i.e., turbl will 
be forced to .false regardless of user input when there is no turbulence model 
in the simulation. 

&boundary_output_variables 


number_of _boundaries 

= 

0 

boundary_list 

= 

1 1 

X 

= 

. true . 

y 

= 

. true . 

z 

= 

. true . 

primitive_variables 

= 

. true . 

rho 

= 

. false 

u 

= 

. false 

V 

= 

. false 

w 

= 

. false 

P 

= 

. false 

entropy 

= 

. false 

mach 

= 

. false 

temperature 

= 

. false 

iblank 

= 

. false 

imesh 

= 

. false 

vort_mag 

= 

. false 

vort_x 

= 

. false 

vort_y 

= 

. false 
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vort_z 

= 

. false 

q_criterion 

= 

. false 

div_vel 

= 

. false 

turbulent _fluctuat ions 

= 

. false 

uuprime 

= 

. false 

vvprime 

= 

. false 

wwprime 

= 

. false 

uvprime 

= 

. false 

uwprime 

= 

. false 

vwprime 

= 

. false 

cp 

= 

. false 

dp_pinf 

= 

. false 

volume 

= 

. false 

residuals 

= 

. false 

resl 

= 

. false 

res2 

= 

. false 

res3 

= 

. false 

res4 

= 

. false 

res5 

= 

. false 

res_gcl 

= 

. false 

primitive_tavg 

= 

. false 

rho_tavg 

= 

. false 

u_tavg 

= 

. false 

v_tavg 

= 

. false 

w_tavg 

= 

. false 

P-tavg 

= 

. false 

primitive_trms 

= 

. false 

rho_trms 

= 

. false 

u_trms 

= 

. false 

v_trms 

= 

. false 

w_trms 

= 

. false 

p_trms 

= 

. false 

lambdal 

= 

. false 

lambda2 

= 

. false 

lambdas 

= 

. false 

lambdad 

= 

. false 

lambdas 

= 

. false 

lambdab 

= 

. false 

lambda? 

= 

. false 

htot 

= 

. false 

ttot 

= 

. false 

ptot 

= 

. false 

etot 

= 

. false 

processor_id 

= 

. false 

turb_ke 

= 

. false 
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turb_diss 

= 

. false 

mu_t 

= 

. false 

turbl 

= 

. false 

turb2 

= 

. false 

turb3 

= 

. false 

turb4 

= 

. false 

turbS 

= 

. false 

turb6 

= 

. false 

turb7 

= 

. false 

turresl 

= 

. false 

turres2 

= 

. false 

turres3 

= 

. false 

turres4 

= 

. false 

turresS 

= 

. false 

turres6 

= 

. false 

turres7 

= 

. false 

de_turbl 

= 

. false 

slen 

= 

. false 

tt 

= 

. false 

tv 

= 

. false 

sonic 

= 

. false 

mixture_mol_weight 

= 

. false 

mixture_density 

= 

. false 

ev 

= 

. false 

rho_i(l :n_species) 

= 

. false 

mu 

= 

. false 

id_12g 

= 

. false 

yplus 

= 

. false 

recovery_temperature 

= 

. false 

turb_mach 

= 

. false 

turbindex 

= 

. false 

average_velocity 

= 

. false 

uavg 

= 

. false 

vavg 

= 

. false 

wavg 

= 

. false 

surf ace_normals 

= 

. false 

cf _x 

= 

. false 

0 

l-h 

1 

= 

. false 

0 

l-h 

1 

N 

= 

. false 

skinfr 

= 

. false 

cq 

= 

. false 

shear_x 

= 

. false 

shear_y 

= 

. false 

shear_z 

= 

. false 

heating 

= 

. false 
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mdot 

= .false 

utau_wf 

= .false 

phi_wf 

= .false 

mu_t_wf 

= .false 

k_wallfunction_bc 

= .false 

omega_wallfunction_bc 

= .false 


number_of -boundaries = 0 

Number of boundary patches given in boundary.list (if -1 is given, this 
number is computed from boundary_list) 

boundary.list = ’ ’ 

List of boundary patch numbers. Commas and dashes can be used to 
specify ranges, i.e., ’1,2, 5-7 ’ . If nothing is specihed, then all but flow- 
through boundaries are output for 3D or a single symmetry plane in 
2D. 

X = .true. 

X-coordinate 
y = .true. 

V -coordinate 
z = .true. 

Z-coordinate 

primitive_variables = .true. 

Output primitive variables: rho, u, v, w, and p 

rho = .false. 

Density 
u = .false. 

X-component of velocity 
V = .false. 

X-component of velocity 
w = .false. 

Z-component of velocity 
p = .false. 

Pressure 
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entropy = .false. 
Entropy 


mach = .false. 

Mach number 
temperature = .false. 

Temperature 
iblank = .false. 

I-blanking variable (default becomes .true, for overset mesh cases) 
imesh = .false. 

For overset mesh systems, index of associated component grid where 0 
indicates background grid 

vortunag = .false. 

Vorticity magnitude 

vort_x = .false. 

X-component of vorticity 

vort_y = .false. 

E-component of vorticity 

vort_z = .false. 

Z-component of vorticity 

q_criterion = .false. 

Q Criterion, the second invariant of VE 

div_vel = .false. 

Velocity divergence 

turbulent,! luctuations = .false. 

Activate all the following XYprime turbulent shear stresses normalized by 
the dehnition of these variables depends on the turbulence model, 
see http://turbmodels.larc.nasa.gov/noteonrunning.html for details 

uuprime = .false. 

Turbulence fluctuation, u'u' 

vvprime = .false. 

Turbulence fluctuation, v'v' 
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wwprime = .false. 

Turbulence fluctuation, w'w' 
uvprime = .false. 

Turbulence fluctuation, u'v' 
uwprime = .false. 

Turbulence fluctuation, u'w' 
vwprime = .false. 

Turbulence fluctuation, v'w' 
cp = .false. 

Pressure coefficient 
dp_pinf = .false. 

Normalized delta pressure (p — Poo)/Poo 
volume = .false. 

Dual-cell volume size 
residuals = .false. 

Activate all resN variables. 
resl = .false. 

Residual of equation 1, density 
res2 = .false. 

Residual of equation 2, x-momentum 
res3 = .false. 

Residual of equation 3, y-momentum 
res4 = .false. 

Residual of equation 4, 2 :-momentum 
res5 = .false. 

Residual of equation 5, energy 
res_gcl = .false. 

For moving meshes, residual of grid conservation law 
primitive.tavg = .false. 

Output time-averaged primitives (requires &time_avg_params namelist): 
rho.tavg, u_tavg, v_tavg, w_tavg, and p_tavg 
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rho.tavg = .false. 

Time- averaged density 
u_tavg = .false. 

Time-averaged x-component of velocity 
v_tavg = .false. 

Time-averaged y-component of velocity 
w_tavg = .false. 

Time-averaged ;^-component of velocity 
p_tavg = .false. 

Time- averaged pressure 
primitive_trms = .false. 

Output root mean squared primitives (requires &time_avg_params namelist): 
rho.trms, u_trms, v_trms, w_trms, and p_trms 

rho_trms = .false. 

RMS-average of density 

u_trms = .false. 

RMS-average of x-component of velocity 
v_trms = .false. 

RMS-average of y-component of velocity 
w_trms = .false. 

RMS-average of ;^-component of velocity 
p_trms = .false. 

RMS-average of pressure 
lambdal = .false. 

Adjoint Lagrange multiplier for equation 1 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lajnbda2 = .false. 

Adjoint Lagrange multiplier for equation 2 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambdas = .false. 

Adjoint Lagrange multiplier for equation 3 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 
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Icanbda4 = .false. 


Adjoint Lagrange multiplier for equation 4 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambdas = .false. 

Adjoint Lagrange multiplier for equation 5 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambdas = .false. 

Adjoint Lagrange multiplier for equation 6 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

lambda? = .false. 

Adjoint Lagrange multiplier for equation 7 (when running the adjoint, 
the primitive variables are turned off, and this is turned on) 

htot = .false. 

Total enthalpy per unit volume 
ttot = .false. 

Total temperature 
ptot = .false. 

Total pressure 
etot = .false. 

Total energy per unit volume 
processor_id = .false. 

Processor on which a node resides 
turb_ke = .false. 

Turbulence kinetic energy 
turb_diss = .false. 

Turbulence dissipation rate 
mu_t = .false. 

Turbulent eddy viscosity 
turbl = .false. 

Turbulence variable 1 (model dependent) 
turb2 = .false. 

Turbulence variable 2 (model dependent) 
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turbS = .false. 


Turbulence variable 3 (model dependent) 
turb4 = .false. 

Turbulence variable 4 (model dependent) 
turbS = .false. 

Turbulence variable 5 (model dependent) 
turbS = .false. 

Turbulence variable 6 (model dependent) 
turb7 = .false. 

Turbulence variable 7 (model dependent) 
turresl = .false. 

Residual of 1st turbulence equation 
turres2 = .false. 

Residual of 2nd turbulence equation 
turresS = .false. 

Residual of 3rd turbulence equation 
turres4 = .false. 

Residual of 4th turbulence equation 
turresS = .false. 

Residual of 5th turbulence equation 
turresS = .false. 

Residual of 6th turbulence equation 
turres7 = .false. 

Residual of 7th turbulence equation 
de_turbl = .false. 

Discretization error of 1st turbulence equation 
slen = .false. 

Length to the nearest solid wall boundary 
tt = .false. 

Translational temperature, only for eqn.type = 


’ generic^ 
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tv = .false. 

Vibrational temperature, only for eqn.type = 'generic' 
sonic = .false. 

Frozen speed of sound, only for eqn.type = 'generic' 
mixture_mol_weight = .false. 

Mixture molecular weight, only for eqn.type = 'generic' 
mixture_density = .false. 

Mixture density, only for eqn_type = 'generic' 
ev = .false. 

Vibrational energy, only for eqn.type = 'generic' 
rho_i(l :n_species) = .false. 

Species concentration, only for eqn_type = 'generic' 
mu = .false. 

Total viscosity 
id_12g = .false. 

Local-to-global node map 
yplus = .false. 

Dimensionless wall distance, 
recovery_temperature = .false. 

Recovery temperature (for eqn_type = 'generic', a Prandtl number 
of 0.72 is assumed) 

turbunach = .false. 

Turbulent Mach number 

turbindex = .false. 

Turbulent index 

average_velocity = .false. 

Turns on uavg, vavg, wavg 

uavg = .false. 

X-component of average velocity near a wall (used to plot surface stream- 
lines) 
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vavg = .false. 


Y -component of average velocity near a wall (used to plot surface stream- 
lines) 

wavg = .false. 

Z-component of average velocity near a wall (used to plot surface stream- 
lines) 

surf ace_normals = .false. 

Turns on surface normals: xnormal, ynormal, znormal; direction of the 
normal points into the computational domain. Note that individual nor- 
mal components are not selectable. 

cf_x = .false. 

X-component of skin friction 

cf_y = .false. 

y-component of skin friction 

cf_z = .false. 

Z-component of skin friction 

skinfr = .false. 

Skin friction magnitude with sign determined by the inner product of 
the skin friction vector and the freestream velocity vector 

cq = .false. 

Temperature gradient normal to the wall, with “dimensions” of nondi- 
mensional temperature per unit grid length for eqn_type = ‘ compressible ’ . 
Heating rate non-dimensionalized by PooV^ for eqn_type = ‘ generic ’ . 

shear_x = .false. 

X-component of shear on the boundary, in MKS units 
shear_y = .false. 

X-component of shear on the boundary, in MKS units 
shear_z = .false. 

Z-component of shear on the boundary, in MKS units 
heating = .false. 

Heating on the boundary in Watts per centimeter squared (for eqn.type 
= ' compressible’ , make sure the grid is in meters) 
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mdot = .false. 

Dimensionless blowing rate non-dimensionalized by PooVoo 
utau_wf = .false. 

Friction velocity calculated from a wall function model. 
phi_wf = .false. 

Pressure gradient term from a wall function model. 
mu_t_wf = .false. 

Wall function turbulent eddy viscosity at the wall. 
k_wallfunction_bc = .false. 

Turbulent kinetic energy wall function boundary condition. 
omega_wallfunction_bc = .false. 

Omega wall function boundary condition. 
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B . 4 . 2 5 ^sampling out put variables 

This namelist controls output of variables from user defined regions of the 
computational domain. To use sampling, the &sampling_parameters namelist 
must be used to dehne the sampling geometries and the sampling_frequency ( : 

) set for each geometry. 

The resulting sampling data hies will have the following naming convention: 

[project_rootname] _tec_sampling_geom [G] _timestep [T] ( . dat I .pit) if N > 0 
[project_rootname] _tec_sampling_geom[G] ( .dat I .pit) if N < 0 

where G = 1,2,. . . ,number_of .geometries, and T is the iteration number. The 
hie extension is .dat for ASCII Tecplot™ format and .pit for binary Tecplot™ 
format. A global image of the sampling surface is output with the zone title 
“time O.OOOOOOOE+00 geom 3” where the time value is the integer iteration 
number for steady-state cases, and the current (nondimensional) time for time- 
dependent cases. 

A request to output an undehned variable will overruled, i.e., turbl will 
be forced to .false regardless of user input when there is no turbulence model 
in the simulation. 


&sampling_output_variables 


X 

= 

■true . 

y 

= 

■true . 

z 

= 

.true . 

primitive_variables 

= 

.true . 

rho 

= 

.false 

rho_i ( : ) 

= 

.false 

u 

= 

.false 

V 

= 

.false 

w 

= 

.false 

P 

= 

.false 

entropy 

= 

.false 

mach 

= 

.false 

temperature 

= 

.false 

tt 

= 

.false 

tv 

= 

.false 

iblank 

= 

.false 

imesh 

= 

.false 

vort_mag 

= 

.false 

vort_x 

= 

.false 

vort_y 

= 

.false 

vort_z 

= 

.false 

q_criterion 

= 

.false 

div_vel 

= 

.false 

turbulent .fluctuations 

= 

.false 
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uuprime 

vvprime 

wwprime 

uvprime 

uwprime 

vwprime 

cp 

dp_pinf 

volume 

residuals 

resl 

res2 

res3 

res4 

res5 

res_gcl 

rho_tavg 

primitive_tavg 

u_tavg 

v_tavg 

w_tavg 

P-tavg 

mu_t_tavg 

vort_mag_tavg 

vort_x_tavg 

vort_y_tavg 

vort_z_tavg 

primitive_trms 

rho_trms 

u_trms 

v_trms 

w_trms 

p_trms 

lambdal 

lambda2 

lambdas 

lambdad 

lambdas 

lambdas 

lambda? 

htot 

ttot 

ptot 

etot 

processor_id 


= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
= .false. 
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turb_ke 

= 

■false 

turb_diss 

= 

■false 

mu_t_wf 

= 

■false 

mu_t 

= 

■false 

turbl 

= 

■false 

turb2 

= 

■false 

turb3 

= 

■false 

turb4 

= 

■false 

turbS 

= 

■false 

turb6 

= 

■false 

turb7 

= 

■false 

turresl 

= 

■false 

turres2 

= 

■false 

turresS 

= 

■false 

turres4 

= 

■false 

turresS 

= 

■false 

turres6 

= 

■false 

turres7 

= 

■false 

slen 

= 

■false 

if lagslen 

= 

■false 

hrles_blend 

= 

■false 

vort_x_rms 

= 

■false 

vort_y_rms 

= 

■false 

vort_z_rms 

= 

■false 

vort_mag_rnis 

= 

■false 

yplus 

= 

■false 

cmu_star 

= 

■false 

mu_t_ratio 

= 

■false 

iib 

= 

■false 

iiib 

= 

■false 

uplus 

= 

■false 

kplus 

= 

■false 

wplus 

= 

■false 

yplusretau 

= 

■false 

tllplus 

= 

■false 

tl2plus 

= 

■false 

tlSplus 

= 

■false 

t22plus 

= 

■false 

t23plus 

= 

■false 

t33plus 

= 

■false 

bird_breakdown 

= 

■false 

vgradrho 

= 

■false 

f_rl 

= 

■false 

xi_k 

= 

■false 

re construct ion_limiter_phil 

= 

■false 
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reconstruction_limiter_phi2 = .false. 
reconstruction_limiter_phi3 = .false. 
reconstruction_limiter_phi4 = .false. 
reconstruction_limiter_phi5 = .false. 

X = .true. 

X-coordinate 
y = .true. 

Y -coordinate 
z = .true. 

Z-coordinate 

primitive.variables = .true. 

Output primitive variables: rho, u, v, w, and p 

rho = .false. 

Density 

rho_i(:) = .false. 

Species densities 
u = .false. 

X-component of velocity 
V = .false. 

X-component of velocity 
w = .false. 

Z-component of velocity 
p = .false. 

Pressure 

entropy = .false. 

Entropy 
mach = .false. 

Mach number 
temperature = .false. 

Temperature 
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tt 


.false. 


Translational-rotational temperatnre in the generic gas path 

tv = .false. 

Vibrational-electronic temperatnre in the generic gas path 
iblank = .false. 

I-blanking variable (defanlt becomes .true, for overset mesh cases) 
imesh = .false. 

For overset mesh systems, index of associated component grid where 0 
indicates backgronnd grid 

vortjnag = .false. 

Vorticity magnitnde 

vort_x = .false. 

V-component of vorticity 

vort_y = .false. 

V-component of vorticity 

vort_z = .false. 

Z-component of vorticity 

q_criterion = .false. 

Q Criterion, the second invariant of W 

div_vel = .false. 

Velocity divergence 

turbulent_f luctuations = .false. 

Activate all the following XYprime turbulent shear stresses normalized by 
the definition of these variables depends on the turbulence model, 
see http://turbmodels.larc.nasa.gov/noteonrunning.html for details 

uuprime = .false. 

Turbulence fluctuation, u'u' 

vvprime = .false. 

Turbulence fluctuation, v'v' 

wwprime = .false. 

Turbulence fluctuation, w'w' 
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uvprime = .false. 

Turbulence fluctuation, u'v' 
uwprime = .false. 

Turbulence fluctuation, u'w' 
vwprime = .false. 

Turbulence fluctuation, v'w' 
cp = .false. 

Pressure coefficient 
dp_pinf = .false. 

Normalized delta pressure {p — Poc)/Poc 

volume = .false. 

Dual-cell volume size 
residuals = .false. 

Activate all resN variables 
resl = .false. 

Residual of equation 1, density 
res2 = .false. 

Residual of equation 2, x-momentum 
res3 = .false. 

Residual of equation 3, y-momentum 
res4 = .false. 

Residual of equation 4, z-momentum 
res5 = .false. 

Residual of equation 5, energy 
res_gcl = .false. 

For moving meshes, residual of grid conservation law 
rho.tavg = .false. 

Time- averaged density 
primitive.tavg = .false. 

Output time-averaged primitives (requires &time_avg_params namelist): 
rho.tavg, u_tavg, v_tavg, w_tavg, and p_tavg 
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u_tavg = .false. 

Time- averaged x-component of velocity 
v_tavg = .false. 

Time-averaged y-component of velocity 
w_tavg = .false. 

Time-averaged z-component of velocity 
p_tavg = .false. 

Time- averaged pressure 
mu_t_tavg = .false. 

Time-averaged turbulent eddy viscosity 
vort_mag_tavg = .false. 

Time-averaged vorticity magnitude 
vort_x_tavg = .false. 

Time-averaged x-component vorticity 
vort_y_tavg = .false. 

Time-averaged y-component vorticity 
vort_z_tavg = .false. 

Time-averaged z-component vorticity 
primitive_trms = .false. 

Output root mean squared primitives (requires &time_avg_params namelist): 
rho.trms, u_trms, v_trms, w_trms, and p_trms 

rho_trms = .false. 

RMS-average of density 

u_trms = .false. 

RMS-average of x-component of velocity 
v_trms = .false. 

RMS-average of ^/-component of velocity 
w_trms = .false. 

RMS-average of ;^-component of velocity 
p_trms = .false. 

RMS-average of pressure 
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lambdal = .false. 

Adjoint Lagrange multiplier for equation 1 (when running the 
the primitive variables are turned off, and this is turned on) 

lajibda2 = .false. 

Adjoint Lagrange multiplier for equation 2 (when running the 
the primitive variables are turned off, and this is turned on) 

lambdas = .false. 

Adjoint Lagrange multiplier for equation 3 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda4 = .false. 

Adjoint Lagrange multiplier for equation 4 (when running the 
the primitive variables are turned off, and this is turned on) 

lambdas = .false. 

Adjoint Lagrange multiplier for equation 5 (when running the 
the primitive variables are turned off, and this is turned on) 

lambdas = .false. 

Adjoint Lagrange multiplier for equation 6 (when running the 
the primitive variables are turned off, and this is turned on) 

lambda? = .false. 

Adjoint Lagrange multiplier for equation 7 (when running the 
the primitive variables are turned off, and this is turned on) 

htot = .false. 

Total enthalpy per unit volume 
ttot = .false. 

Total temperature 
ptot = .false. 

Total pressure 
etot = .false. 

Total energy per unit volume 
processor.id = .false. 

Processor on which a node resides 
turb_ke = .false. 

Turbulence kinetic energy 


adjoint. 


adjoint. 


adjoint. 


adjoint. 


adjoint. 


adjoint. 


adjoint. 
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turb_diss = .false. 

Turbulence dissipation rate 
mu_t_wf = .false. 

Turbulent eddy viscosity at the wall from a wall function model. 
mu_t = .false. 

Turbulent eddy viscosity 

turbl = .false. 

Turbulence variable 1 (model dependent) 
turb2 = .false. 

Turbulence variable 2 (model dependent) 
turb3 = .false. 

Turbulence variable 3 (model dependent) 
turb4 = .false. 

Turbulence variable 4 (model dependent) 
turbS = .false. 

Turbulence variable 5 (model dependent) 
turbS = .false. 

Turbulence variable 6 (model dependent) 
turb7 = .false. 

Turbulence variable 7 (model dependent) 
turresl = .false. 

Residual of 1st turbulence equation 
turres2 = .false. 

Residual of 2nd turbulence equation 
turresS = .false. 

Residual of 3rd turbulence equation 
turres4 = .false. 

Residual of 4th turbulence equation 
turresS = .false. 

Residual of 5th turbulence equation 
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turres6 = .false. 

Residual of 6th turbulence equation 
turres7 = .false. 

Residual of 7th turbulence equation 
slen = .false. 

Length to the nearest solid wall boundary 
iflagslen = .false. 

Turbulence model distance function closest boundary entity, (a negative 
sign indicates the node has been prescribed as laminar) 

hrles_blend = .false. 

HRLES blending function 

vort_x_rms = .false. 

RMS-average of x-component of vorticity 

vort_y_rms = .false. 

RMS-average of y-component of vorticity 

vort_z_rms = .false. 

RMS-average of z-component of vorticity 

vort_mag_rms = .false. 

RMS-average of vorticity magnitude 

yplus = .false. 

Dimensionless wall distance, 

cmu_star = .false. 

k — e model turbulent length scale parameter 
mu_t_ratio = .false. 

Ratio of turbulent eddy viscosity to laminar (bulk) viscosity 
lib = .false. 

— trace (Rjj * Rp )/2 
iiib = .false. 
trace (Rjj * Bij * Bij)/3 
uplus = .false. 

Dimensionless velocity, 
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kplus = .false. 


A 

ul 

wplus = .false. 

LOU 

n? 

yplusretau = .false. 


rCr 


tllplus = 

.false. 



tl2plus = 

.false. 



tlSplus = 

.false. 



t22plus = 

.false. 

n - + 
'22 


t23plus = 

.false. 

7-+ 

'23 


tSSplus = 

.false. 

7-+ 

'33 


bird_breakdown = .false. 

Bird continuum breakdown parameter 
vgradrho = .false. 

[u, V, ta] ■ Vp 
f_rl = .false. 

Curvature correction model function 
xi_k = .false. 

Cross- diffusion term for Wilcox k-uj 1998 
reconstruction_limiter_phil = .false. 

(f) for the node-based reconstruction limiters 
reconstruction_limiter_phl2 = .false. 

(j) for the node-based reconstruction limiters 


(equation 1) 
(equation 2) 
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reconstruction_limiter_phi3 = .false. 

(j) for the node-based reconstruction limiters (equation 3) 
reconstruction_limiter_phi4 = .false. 

0 for the node-based reconstruction limiters (equation 4) 
reconstruction_limiter_phi5 = .false. 

(f) for the node-based reconstruction limiters (equation 5) 
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B.4.26 ^sampling parameters 


This namelist specifies the types and frequency of sampling data to be ex- 
ported for visualization. The output variables themselves are specified in the 
&sampling_output_variables namelist. The last dimension of each array 
references the geometry index, which is one to number_of ^geometries. 

&sampling_parameters 


number_of _geometries 

= 

0 

sampling_f requency ( : ) 

= 

0 

label ( : ) 

= 

1 1 

type_of _geometry ( : ) 

= 

' none ' 

crinkle 

= 

.false . 

nodal 

= 

.false . 

plot(:) 

= 

' tecplot 

patch_list_count ( : ) 

= 

0 

patch_list ( : ) 

= 

1 1 

type_of _data( : ) 

= 

' volume ' 

move_with_body ( : ) 

= 

1 1 

boundary_list 

= 

1 1 

def ault_boundary 

= 

. true . 

plane_center (1:3, : ) 

= 

0.0 

plane_normal (1:3, : ) 

= 

0.0 

box_lower_corner (1:3, : ) 

= 

0.0 

box_upper_corner (1:3, : ) 

= 

0.0 

sphere_center (1 :3, : ) 

= 

0.0 

sphere_radius ( : ) 

= 

0.0 

circle_center (1 :3, : ) 

= 

0.0 

circle_normal (1 :3, : ) 

= 

0.0 

circle_radius ( : ) 

= 

0.0 

cylinder_f acel (1 : 3, : ) 

= 

0.0 

cylinder_f ace2(l : 3, : ) 

= 

0.0 

cylinder_radius ( : ) 

= 

0.0 

cone_f acel (1 : 3, :) 

= 

0.0 

cone_face2(l :3, :) 

= 

0.0 

cone_radiusl ( : ) 

= 

0.0 

cone_radius2 ( : ) 

= 

0.0 

cornerl (1 : 3, : ) 

= 

0.0 

corner2(l : 3, : ) 

= 

0.0 

corner3(l : 3, : ) 

= 

0.0 

corner4(l : 3, : ) 

= 

0.0 

number_of _points ( : ) 

= 

0 

pointsd :3, : , : ) 

= 

0.0 

pl_line(l : 3, : ) 

= 

0.0 

p2_line(l : 3, : ) 

= 

0.0 

schlieren_aspect 

= 

1 1 
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window_height ( : ) 
window_width( : ) 
window_center (1 :3, : ) 
number_of _rows( : ) 
number_of _columns ( : ) 
model_center (1:3, : ) 
plot_lines ( : ) 
make _ shadow 
blanking_list_count ( : ) 
blanking_list ( : ) 
isosurf _variable ( : ) 
isosurf _value ( : ) 
isosurf _box( : ) 
x_range_lower ( : ) 
x_range_upper ( : ) 
y_range_lower ( : ) 
y_range_upper ( : ) 
z_range_lower ( : ) 
z_range_upper ( : ) 
isosurf _dist_threshold( : ) 
variable_list ( : ) 
snap_output_xyz 
dist_tolerance 
fwh_f ormatted 
append_history ( : ) 
asynchronous_fwh 
boundary _point (1 : 3, : ) 
boundary ( : ) 
need_wall_data( : ) 
ref erence_length 


0.0 

0.0 

0.0 

0 

0 

0.0 

.false . 
.false . 

0 

I I 

'P' 

0.0 

.false . 
- 1.0 
1.0 
- 1.0 
1.0 
- 1.0 
1.0 

0.0 

I I 

. true . 
l.Oe-3 
.false . 
.false . 
.false . 
0.0 
0 

.false . 
0.0 


number.of .geometries = 0 

This is the total number of sampling geometries. 


sampling.! requencyC : ) = 0 

This specihes the iteration interval at which sampling is performed. The 
special value of -1 means to only perform sampling at the end of a 
successful run. 


labeK:) = ’ ’ 

This customizes the hlename of sampling output. When it is blank, the 
hie will be [project_rootname] _tec_sampling_geomN. (dat , pit) where 
N is the sampling geometry number, .dat is ASCII format, and .pit is 
binary format. 
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type.of -geometry (: ) = ’none’ 

This is the type of sampling geometry, 

' streamsurf ace ’ is a stream surface, requires number_of _points and 
points. 

' boundary.points ’ for boundary point sampling, requires number _of .points 
and points, modihed by snap_output_xyz and dist_tolerance. 

' volume.points ’ for point sampling in the domain, requires number _of .points 
and points. 

' schlieren’ is a schlieren image via an integral of the refractive index 
held, requires number.of .rows, number.of .columns, windowTieight, window_width, 
window_center, and schlieren.aspect. It is controlled by make_shadow 
and plot-lines. 

' isosurface ’ is an isosurface that requires isosurf .variable and isosurf .value. 
It is controlled by *_range.lower and *.range_upper. 

'box’ samples a the surface of a box. It requires box_lower_corner and 
box_upper_corner. 

'sphere’ samples a spherical surface. It requires sphere.center and 
sphere_radius. 

'cylinder’ samples a cylindrical surface. It requires cylinder.! acel, 
cylinder.! ace2, and cylinder.radius. 

'cone’ samples a conic surface. It requires cone_facel, cone_face2, 
cone_radiusl, and cone_radius2. 

'plane’ samples a plane. It requires plane.center and plane jiormal. 

'quad’ samples a quadrilateral. It requires cornerl, corner2, corners, 
corner4, and window_normal. 

'circle’ samples a circle. It requires circle.center, circleuaormal, 
and circle_radius. 

' line’ is line sampling, which requires pl.line and p2_line. 
crinkle = .false. 

This snaps the sampling surface to nearest grid faces instead of using 
linear interpolation. 

nodal = .false. 

This uses the nearest nodal values instead of interpolating. 
plot(:) = ’tecplot’ 

This is the format of sampling output. 
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'tecplot' Tecplot™ format. 

'fwh’ format for Ffowcs Williams-Hawkings analysis. 

' serial_history ' custom low-overhead point sampling format where 
all locations listed once at the top and then just the requested values 
per sampling_frequency. 

patch_list_count ( : ) = 0 

This is the number of patches in patch_list. 

patch_list ( : ) = ’’ 

A string list of patch face IDs to limit boundary survey to a subset of 
the boundary faces. Commas and dashes can be used to specify ranges, 
i.e., '1,2,5-7C 

type.of _data( : ) = ’volume’ 

The source of data for extracting the requested sampling variables for 
each type_of .geometry. 

' volume ’ extract data from the computational volume. 

' boundary ’ extract data from a boundary. 

'integrated’ extract data from the computational volume and inte- 
grate over dehned geometry. 

move_with_body ( : ) = ’’ 

Move the sampling geometry with the body if body is in motion. Use 
the hxed inertial reference frame when blank. 

boundary.list = ’ ’ 

List of patches to include when sampling boundaries; Commas and 
dashes can be used to specify ranges, i.e., ’1,2, 5-7’ . 

default .boundary = .true. 

Use FUN3D default solid- wall-only boundary patches when sampling 
boundary points, i.e., ignore symmetry, slip, and flow-through bound- 
aries. 

plane .center (1 : 3, : ) = 0.0 

This is a point on a requested sampling ’ plane ’ ; it hxes the location, 
planejiormald :3, : ) = 0.0 

This is a normal vector of sampling ’ plane ’ ; it hxes the orientation. 

box.lower. corner (1 : 3, : ) = 0.0 

This is the coordinate of the lower corner of a ’ box ’ . 
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box_upper_corner(l : 3, : ) = 0.0 

This is the coordinate of the upper corner of a ' box ' . 

sphere_center(l :3, : ) = 0.0 

This is the coordinate of ’ sphere ' center; it hxes the location. 
sphere_radius( : ) = 0.0 

This is the radius for ' sphere ’ ; it hxes the size. 
circle_center(l :3, : ) = 0.0 

This is the coordinate of center of a ’ circle' ; it hxes the location. 
circle_normal(l :3, : ) = 0.0 

This is the normal vector for a ' circle’ ; it hxes the orientation. 
circle_radius( : ) = 0.0 

This is the radius for a ’ circle’ ; it hxes the size, 
cylinder.! acel (1 : 3, : ) = 0.0 

This is the coordinate for the center of the hrst face of a ’ cylinder’ . 
cylinder.! ace2(l : 3, : ) = 0.0 

This is the coordinate for center of the second face of a ’ cylinder’ . 

cylinder.radius ( : ) = 0.0 
This is the radius of a ’ cylinder’ . 

cone_!acel(l :3, : ) = 0.0 

This is the coordinate for center of the hrst face of a ’ cylinder’ . 
cone_!ace2(l :3, : ) = 0.0 

This is the coordinate for center of the second face of a ’ cylinder’ . 
cone.radiusl ( : ) = 0.0 

This is the radius of the hrst face of a ’ cone ’ . 
cone.radius2( : ) = 0.0 

This is the radius of the second face of a ’ cone ’ . 
cornerl (1 : 3, : ) = 0.0 

This is the coordinate of the hrst corner of a ’ quad ’ ; the corners proceed 
clockwise. 
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corner2(l :3, : ) = 0.0 

The coordinate of the second corner of a ’ quad' . 
corners (1 : 3, : ) = 0.0 

The coordinate of the third corner of a ’ quad ’ . 
corner4(l :3, : ) = 0.0 

The coordinate of the fourth corner of a ' quad’ . 
number_of ^points ( : ) =0 

This is the number of points to be sampled by ’ boundary _point ’ or 
’ volume.point ’ . 

pointsCl :3, : , : ) = 0.0 

These are the coordinates of boundary_point and volume_point sam- 
pling. The hrst index is the Cartesian direction, the second index is the 
geometry, and the last index is the point in this geometry. 

pl_line(l:3, :) =0.0 

This is the hrst end point of a line in line sampling. 
p2_line(l :3, : ) = 0.0 

This is the second end point of a line in line sampling. 
schlieren_aspect = ’ ’ 

This is the Cartesian direction for ’schlieren’ view, 

' y ’ Schlieren viewing along y axis. 

'z’ Schlieren viewing along 2 ; axis. 

' yl ’ Schlieren viewing along y axis. 

'zl’ Schlieren viewing along axis. 

' ’ Schlieren viewing along windowuaormal. 

window_height ( : ) = 0.0 

This is the window height for ’ schlieren’ . 

window_width( : ) = 0.0 

This is the window width for ’ schlieren’ . 

window_center(l :3, : ) = 0.0 

This is the window center for ’ schlieren’ . 
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number _of_rows ( : ) =0 

This is the vertical number of pixels in the ’ schlieren' window. 
number_of _columns ( : ) = 0 

This is the horizontal number of pixels in the 'schlieren’ window. 

model_center(l :3, : ) = 0.0 

This is the model center for ’ schlieren' . 

plot_lines( : ) = .false. 

This plots lines for ’ schlieren' . 
make_shadow = .false. 

The boundary will cast a shadow in schlieren output. 
blanking_list_count ( : ) = 0 

This is the number of boundaries to search for ’ schlieren' boundary 
shadow. 

blanking.list ( : ) = ’’ 

This is a list of boundaries to search for ' schlieren’ shadow. Commas 
and dashes can be used to specify ranges, i.e., ’1,2, 5-7’ . 

isosurf _variable( : ) = ’p’ 

This is the variable used to dehne the geometry of an ’ isosurface ’ and 
isocrinkle. 

'p’ Pressure. 

' rho ’ Density. 

' u ’ X-component of velocity. 

' V ’ Y -component of velocity. 

' w ’ Z-component of velocity. 

'vort_x’ X-component of vorticity. 

'vort_y’ X-component of vorticity. 

'vort_z’ Z-component of vorticity. 

'vort_mag’ Total magnitude of vorticity vector. 

' vort Jiag_avg’ Average total magnitude of vorticity vector. 

' vort Jiag_rms ’ RMS total magnitude of vorticity vector. 

' q_criterion’ Q-criterion. 

'mach’ Mach number. 
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'temperature’ Temperature. 

'p_tavg’ Time average pressure. 

'rho.tavg’ Time average density. 

'u_tavg’ Time average r-component of velocity. 

'v_tavg’ Time average ^/-component of velocity. 

'w_tavg’ Time average ;^-component of velocity. 

' p_trms ’ RMS of pressure. 

'rho.trms’ RMS of density. 

' u_trms ’ RMS of the x-component of velocity. 

' v_trms ’ RMS of the y-component of velocity. 

' w_trms ’ RMS of the ;^-component of velocity. 

'critical.d’ critical d 
' sla’ other option 
'sib’ other option 
'si’ other option 
' s2 ’ other option 

' lambdal ’ Adjoint variable for the 1st governing equation. 

' lambda2 ’ Adjoint variable for the 2nd governing equation. 

' lambdas ’ Adjoint variable for the 3rd governing equation. 

' lambda4’ Adjoint variable for the 4th governing equation. 

' lambdas ’ Adjoint variable for the 5th governing equation. 

' lambdas ’ Adjoint variable for the 6th governing equation. 

' lambda?’ Adjoint variable for the 7th governing equation. 

' processor_id’ The assigned processor ID. 

' bird_breakdown’ Bird breakdown factor. 
isosurf _value( : ) = 0.0 

This is the value of isosurf _variable( : ) to create the ’isosurface’ 
and isocrinkle geometry. 

isosurf _box( : ) = .false. 

This clips the sampling geometry to be inside a box sized by *_range_* 
within isosurf _dist_threshold. 

x_range_lower ( : ) = -1.0 

This limits isosurf ace or isocrinkle when isosurf _box( : ) = .true. 
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x_range_upper ( : ) = 1.0 

This limits isosurf ace or isocrinkle when isosurf _box( : ) = .true. 
y_range_lower ( : ) = -1.0 

This limits isosurf ace or isocrinkle when isosurf _box( : ) = .true. 
y_range_upper ( : ) = 1.0 

This limits isosurf ace or isocrinkle when isosurf _box( : ) = .true. 
z_range_lower ( : ) = -1.0 

This limits isosurf ace or isocrinkle when isosurf _box( : ) = .true. 
z_range_upper ( : ) = 1.0 

This limits isosurf ace or isocrinkle when isosurf _box( : ) = .true. 
isosurf _dist_threshold( : ) = 0.0 

This trims portions of an isosurface or isocrinkle that have a dis- 
tance to the surface less then this threshold. It requires isosurf _box( : 
) = .true. 

variable_list ( : ) = ’’ 

These variables augment &sampling_output_variables for this sam- 
pling object. 

snap_output_xyz = .true. 

This snaps the requested points to the nearest surface, 
dist.tolerance = l.Oe-3 

This is the tolerance used when snap_output_xyz is engaged. 
fwh_f ormatted = .false. 

Write Ffowcs Williams-Hawkings in Fortran unformatted format. The 
default is Fortran stream (C-binary). 

append_history ( : ) = .false. 

This option removes the step number from the hlename and opens it 
with append. 

asynchronous_fwh = .false. 

This uses asynchronous I/O for permeable FWH output, 
boundary.point (1 : 3, : ) = 0.0 

This dehnes the location on a boundary where the friction velocity is 
to be calculated for use in plotting data in wall units. Additional input 
that is required is boundary (ib) . 
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boundaryC:) = 0 

This defines the boundary on which boundary _point (1 : 3 , ib) will be 
found. 

need_wall_data( : ) = .false. 

This option activates the calculation of the friction velocity at a point 
on a wall for plotting of data in wall units. Other required input would 
be boundary (ib) and boundary_point ( : ,ib). A sample asking for a 
boundary layer profile in wall units on boundary number 2 at the point 
(4., 0.05,0.) could have the following form; 

&sampling_parameters 
number_of _geometries = 1 
type_of _geometry (1) = 'line' 

pl_line(:,l) =4.0,0.05,-10. 

p2_line(:,l) =4.0,0.05, 10. 

boundary (1) = 2 

boundary_point ( : , 1) = 4.0,0.05,0. 

need_wall_data(l) = T 

variable_list ( 1 ) = ' uplus , yplus , kplus , wplus ' 
sampling_frequency (1) = -1 
/ 

ref erence_length = 0.0 

This is the reference length for Rcr used in &sampling_output_variables. 
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B.4.27 &slice data 


This namelist specifies boundary slices for visualization and to obtain loads. 
Output frequency is controlled by slice_f req in the feglobal namelist, where 
zero for no output, -1 for output at the end of run, and a positive integer for 
periodic output. 

This is a limited ability to take slices through boundary surfaces. For 
example, spanwise cuts along a wing may be extracted, and then the resulting 
pressure and skin friction data may be plotted at each station. Slices can 
only be extracted in Cartesian planes (e.g., constant y). For moving-body 
cases, the slices may be taken at constant coordinate positions in the body- fixed 
coordinate system, in which case the slices will not generally be in Cartesian 
planes in inertial space. 

Each slice will be written as one or more zones (loops) in an ASCII for- 
matted Tecpiot™ file with the naming convention: 

[pro j ect_rootname] _slice . dat 

The variables output to this file are: x, y, z, cp, cfx, cfy, and cfz at each 
output time step. These slicing output variables are not customizable by the 
user. 

Slicing occurs in the inertial frame, unless an alternate reference frame is 
specified. For stationary geometries, the inertial frame is the only option. For 
moving body cases, either the frame of one of the moving bodies or an observer 
frame may specified. 

When slicing boundary surfaces, a file called slice. info is output that 
echos much of the input data. When the slicing is successful, the file will also 
contain information about the number of points in the slice. 

Below, namelist variables are defined. See section B.4.27 for some impor- 
tant considerations when using this capability. 

&slice_data 


nslices 

= 

1 

replicate_all_bodies 

= 

.false . 

slice_x( : ) 

= 

.false . 

slice_y ( : ) 

= 

. true . 

slice_z( : ) 

= 

.false . 

slice_location( : ) 

= 

0.0 

slice_increment 

= 

0.0 

xx_box_max( : ) 

= 

huge (1 . 0) 

yy_box_max( : ) 

= 

huge (1 . 0) 

zz_box_max( : ) 

= 

huge (1 . 0) 

xx_box_min( : ) 

= 

-huge (1 . 0) 

yy_box_min( : ) 

= 

-huge (1 . 0) 

zz_box_min( : ) 

= 

-huge (1 . 0) 
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slice_xmc( : ) 


= 

huge (1 . 0) 


slice_ymc( : ) 


= 

huge (1 . 0) 


slice_zmc( : ) 


= 

huge (1 . 0) 


n_bndrys_to_slice ( : ) 


= 

0 


bndrys_to_slice 


= 

0 


slice_frame ( : ) 


= 

1 1 


slice_group( : ) 


= 

1 


chord_dir ( : ) 


= 

1 


te_def ( : ) 


= 

1 


le_def ( : ) 


= 

30 


corner_angle ( : ) 


= 

120.0 


use_local_chord 


= 

. true . 


tecplot_slice_output 


= 

. true . 


output _sectional_f or ces 

= 

. true . 


slice_initial_coords 


= 

.false . 


custom_transf orm(l , 1 , 

1:4) 

= 

1.0, 0.0, 

0.0, 0.0 

oust om_transform( 1,2, 

1:4) 

= 

0.0, 1.0, 

0.0, 0.0 

custom_transforni(l ,3, 

1:4) 

= 

0.0, 0.0, 

1.0, 0.0 

custom_transform(l ,4, 

1:4) 

= 

0.0, 0.0, 

0.0, 1.0 

output_in_slice_coords( : ) 

= 

.false . 



nslices = 1 

This is the number of slices to create. If negative, then data for only 
one slice station need be input, along with slice_increment, and all the 
data specihed for the first station will be applied to subsequent stations, 
with the exception of the slice location, which will be set using the slice 
increment between stations. 

replicate_all_bodies = .false. 

This will set similar slice stations on multiple bodies with minimal input 
beyond that required for slicing the first body. This is particularly useful 
for rotorcraft applications where multiple blades are to be sliced. This 
variable duplicates the input slice info for all moving bodies, with the 
exception of the slice_frame and the bndrys_to_slice. 

slice_x(:) = .false. 

This extracts the slice at a; = slice.location in the specihed reference 
frame. 

slice_y(:) = .true. 

This extracts the slice dX y = slice.location in the specihed reference 
frame. 
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slice_z(:) = .false. 

This extracts the slice at ;^ = slice_location in the specihed reference 
frame. 

slice_location( : ) = 0.0 

This is the coordinate value at which slice is taken. 
slice_increment = 0.0 

When nslices is negative, this is the increment in slice coordinate be- 
tween consecutive slice stations. 

xx_box jnax ( : ) = huge (1.0) 

This is the maximum x-coordinate used to dehne a bounding box to 
constrain the slicing to hlter unwanted intersections. 

yy_box unax ( : ) = huge (1.0) 

This is the maximum y-coordinate used to define a bounding box to 
constrain the slicing to hlter unwanted intersections. 

zz_boxunax ( : ) = huge (1.0) 

This is the maximum ;^-coordinate used to dehne a bounding box to 
constrain the slicing to hlter unwanted intersections. 

xx_boxunin( : ) = -huge(l.O) 

This is the minimum x-coordinate used to dehne a bounding box to 
constrain the slicing to hlter unwanted intersections. 

yy_boxunin( : ) = -huge(l.O) 

This is the minimum y-coordinate used to dehne a bounding box to 
constrain the slicing to hlter unwanted intersections. 

zz_boxunin( : ) = -huge(l.O) 

This is the minimum ;^-coordinate used to dehne a bounding box to 
constrain the slicing to hlter unwanted intersections. 

slice_xmc ( : ) = huge (1.0) 

This is the x-coordinate of the moment center, in the specihed reference 
frame, for aerodynamic moments acting on the slice. The default value 
will result in the moment center being taken as the computed quarter 
chord of the slice. 

slice_ymc ( : ) = huge (1.0) 

This is the y-coordinate of the moment center, in the specihed reference 
frame, for aerodynamic moments acting on the slice. The default value 
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will result in the moment center being taken as the computed quarter 
chord of the slice. 

slice_zmc ( : ) = huge (1.0) 

This is the z-coordinate of the moment center, in the specihed reference 
frame, for aerodynamic moments acting on the slice. The default value 
will result in the moment center being taken as the computed quarter 
chord of the slice. 

n_bndrys_to_slice( : ) = 0 

This is the number of candidate boundaries to search while computing 
slice-plane intersections. The index is the slice. By default, all solid 
boundaries will be searched. Specifying which boundaries are candidates 
for slicing may speed up the slicing process and can be used to hlter out 
unwanted intersections or to slice non-solid boundaries. 

bndrys_to_slice( : , : ) = 0 

This is the list of n_bndrys_to_slice boundaries, when the variable 
n_bndrys_to_slice is greater than zero. The hrst index is the slice 
and the second index is the boundary. 

slice_frame( : ) = ’’ 

This is the name of the slice reference frame. Blank indicates the iner- 
tial frame. For moving geometries, output may be requested in either 
the reference frame of a particular body, or an “observer” frame. To 
specify the frame of a particular body, use the body_name entered in the 
febody .definitions namelist. To specify the observer frame dehned in 
the feobserver Jiotion namelist, use ' observer h 

slice_group( : ) = 1 

This assigns this slice to a particular group number. Within a group, 
slice locations must be given in ascending order. 

chord_dir(:) = 1 

This is the direction of local chord relative to the direction from leading 
edge to trailing edge, in the slice plane. The value 1 indicates local chord 
in direction from leading edge to trailing edge. The value —1 indicates 
local chord in direction from trailing edge to leading edge. Determination 
of the leading and trailing edges is described below. 

te_def ( : ) =1 

This is the number of points or line segments to consider when dehning 
the trailing edge of the slice (see Fig. B2). A value of 1 dehnes the 
trailing edge as the aft-most point. This is best for sharp trailing edges. 
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A positive number greater than 1 initiates a search over the aft-most 
te_def segments for corners, after which the trailing edge is taken as 
the average coordinate over all the detected corners. Two corners are 
assumed to be the desired number, and warnings are output if only- 
one or more than two are found. The value of te_def must be chosen 
judiciously. It should be large enough to allow both corners to be found 
but not so large as to cause excessive searching or for any non-trailing 
edge corners to be found. A positive value of te_def is best for and 
recommended only for squared-off trailing edges. A negative number 
indicates a parabolic £t of the aft-most abs(te_def) points, which is 
best for rounded or blunted trailing edges. 

le_def(:) = 30 

This is the number of points to consider when dehning the leading edge 
of the slice (see Fig. B3). A value of 1 dehnes the leading edge as the 
forward-most point. Use this if nothing else works or for special cases. A 
positive number indicates a search over the forward-most le_def points 
for the one that has the maximum distance from the previously deter- 
mined trailing edge. A positive number for le_def is generally the best 
choice provided that the trailing edge can be accurately located. A nega- 
tive number indicates a parabolic £t over the forward-most abs(le_def) 
points. 

corner.angle ( : ) = 120.0 

This is used in conjunction with a te_def greater than 1. Angles between 
adjacent sliced segments that are less than corner.angle degrees will be 
considered a corner between the two segments. For squared-off trailing 
edges, two and only two corners should be detected; warnings are output 
if only one or more than two are found. 

use_local_chord = .true. 

Use the computed local (sectional) chord based on the computed lead- 
ing edge and trailing edge locations to normalize the sectional force 
and moment data. When .false., the value of x_moment_length in 
&f orcejnoment_integ_properties will be used instead of the locally 
computed chord. 

tecplot_slice_output = .true. 

This outputs the sliced data to a formatted Tecplot™ file that is named 
[project_rootnamej_slice.dat. This hie can become very large for 
unsteady hows with frequently written data at many slice locations. 

output_sectional_f orces = .true. 

This outputs detailed force and moment data for each slice to a formatted 
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file, [project_rootname] ,sectional_forces. This file contains force 
and moment data, like that in the [project_rootname] .forces hie, for 
each and every slice. In addition, it contains geometrical data for each 
slice (leading and trailing edge coordinates, moment center, etc.) This 
hie can become very large for unsteady hows with frequently written data 
at many slice locations. The data in the hie, especially the geometry 
data, can be useful to assess whether the slicing is working as expected. 

slice_initial_coords = .false. 

This allows faster slicing for some cases by only computing slice inter- 
polation coefficients once. 

custom.transf orm(l , 1 , 1 : 4) = 1.0, 0.0, 0.0, 0.0 

This is a user-specihed transform matrix to allow slicing in a custom 
coordinate system. 

output_in_slice_coords ( : ) = .false. 

This outputs sliced data in the user-specihed coordinate system. The 
default outputs the data in the slice_frame, which is only available if 
custom.transf orm is set. 

Important Considerations for Determination of Leading And Trail- 
ing Edges Determining the locations of airfoil leading and trailing edges 
is especially important for rotorcraft applications where airloads are usually 
examined (and provided to a CSD code, if applicable), in an airfoil section- 
aligned coordinate system. The leading and trailing edge points determine the 
orientation of this section aligned coordinate system. In the section-aligned 
system, the local x coordinate is aligned with the local chord, positive in the 
direction from the leading edge to the trailing edge. The local span direction is 
dehned by the moment centers at the slice.location points, positive in the 
direction of increasing slice_location. The local normal direction is dehned 
as the cross product of the local chord vector and local span vector. When 
slicing boundary data, the computed forces are computed in both the selected 
frame of reference (see slice_frame) and in an airfoil section aligned system. 
If the data in the section-aligned system is irrelevant to you, then you do not 
need to worry about choosing the detection parameters carefully; the default 
values should be reasonable. However, if resolution of forces and moments 
into a section-aligned system is important to you, then there are a number of 
things that should be considered: 

1. Make sure the chord direction chord_dir is correct; the default is that 
going from the leading edge to the trailing edge is the same as traveling in 
the positive “chordwise” coordinate direction. For most applications this 
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is the usual situation; however, the convention for rotorcraft applications 
is the opposite, requiring chord.dir = -1. 

2. Since the best option for determining the leading edge uses the trailing 
edge location (le_def > 1), care should be taken to get the trailing edge 
correct. For sharp trailing edges, this is very simple since the default of 
te_def = 1 (i.e., use the aft-most point) is the best option. However, 
smoothly blunted or squared-off trailing edges are more difficult. When 
the boundary surface of an unstructured mesh is sliced, the resulting 
section will be comprised of line segments determined by the intersec- 
tion of the specihed plane and the edges of the surface triangles. These 
segments and the points that make up the segments will not usually be 
the same as the surface points; typically there are more segments and 
points arising from intersected triangles, as illustrated in Fig. Bl. This 
greater point count should influence the selection of te_def and le_def 
values. You will need enough segments (te_def and le_def) to ensure 
that both corners are detected, but not so many that other, non trailing- 
edge corners (if present) are detected. Another parameter that may be 
of use to aid in the detection of corners is the corner.angle; corners 
with angles larger than corner.angle between adjacent segments will 
require a larger value of corner_angle for detection. 

The resulting section corresponding to the slice depicted in Fig. Bl is 
shown in Fig. B2, where the view is zoomed in to the trailing edge 
region. The aft-most 8 segments (of the approximately 30 segments in 
this view) are shown in red. The computed trailing edge locations using 
two different te_def values are shown. The minimum te_def value at 
this particular station to pick up both corners would be 8, but a value of 
20 was used in case another slice required more segments. If the blade 
was pitched downward rather than upward, then the point chosen by 
te_def = 1 would be the lower corner, rather than the upper corner as 
shown. Thus, when pitching up and down, te_def = 1 with squared-off 
trailing edges can lead to jumps in the trailing edge position as the section 
transitions from pitch up to pitch down. Depending on the thickness of 
the trailing edge, this can lead to jumps in the geometric pitch angle of a 
few tenths of a degree. To avoid this, the option slice_initial_coords 
= .true, will reuse the leading and trailing edges determined from the 
initial grid dehnition, rather than the current, displaced grid location. 

3. Smoothly-blunted (rounded) trailing edges should be done with either 
te_def = 1 (aft-most point) or via a parabolic £t of the aft-most 
abs(te_def) points; the latter option is probably better in general but 
will require some experimentation for the particular case at hand to 
choose the optimal number of points over which to £t the parabola. 
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4. The leading edge is typically easier to determine, if a good trailing edge 
position has already been found. The default value of le_def = 30 
(search the 30 forward-most points for the one with the greatest dis- 
tance from the trailing edge location) should do a decent job for most 
cases. 

Figure B3 shows a sliced section, zoomed in to the leading edge region. 
The forward-most 20 segments (of the approximately 30 segments in this 
view) are shown in red. The computed leading edge locations using two 
different le_def values are shown. In this case, both results are fairly 
close but le_def = 30 has picked out the true leading edge (as judged 
from the leading edge geometry at zero pitch angle). 

5. The leading edge and trailing edge detection schemes can be somewhat 
sensitive to the input choices. For cases that rely on accurate resolution 
of forces and moments into section-aligned coordinates (e.g., rotorcraft), 
it is wise to spend some time up front to make sure that things are 
coming out as expected. To do this, inspect the [project_rootname] 
.sectional_f orces hie for a particular slice station; at each station the 



Figure Bl; View looking upstream from the trailing edge of a rotor blade 
mesh; the light-colored region is the squared-off trailing edge; the red line 
shows the location where an a;=constant slice will be taken; black circles 
indicate surface grid points on the trailing edge. 
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computed leading and trailing edge coordinates will be output. Plot 
the corresponding station from the [project_rootname] _slice.dat, as 
done above, and make sure the computed coordinates are the correct 
ones. If many stations are sliced, it is impractical to inspect all of them 
in this manner, but it is good practice to spot check at least a few 
stations. For moving-geometry cases, try hrst running the case with 
bodyjnotion_only = .true, in the feglobal namelist. This will allow 
output of the [project_rootname] .sectional_f orces and [project_rootname] 
_slice.dat hies without the expense of a how solve or mesh deformation; 
for spot checking you may want to have the slicing done infrequently, per- 
haps using fewer stations than ultimately desired, as these output hies 
can be huge. 

6. While the [project_rootname] .sectional_f orces can be useful for 
spot checking, the data in the hie is not in a format that is amenable to 
plotting. The Fun 3D distribution utils/Rotorcraft directory con- 
tains a utility code that will read in both the hies slice. info and 
[project_rootname] .sectional_f orces to output Tecplot™ hies, for 
each slice group, containing force and moment data in the section-aligned 
coordinate system, as well as geometry data (leading edge, trailing edge. 



Figure B2: Sliced section corresponding to Fig. Bl; zoomed in to the 
trailing edge region. 
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quarter-chord coordinates, and pitch angle). 

7. After making sure that the leading edge and trailing edge positions are 
being computed correctly, you may want to turn off one or both of 
the [project_rootname] ,sectional_forces and [project_rootname] 
_slice.dat hies unless needed. For instance, in rotorcraft applications 
with coupling to external CSD codes, although the blade boundary sur- 
faces must be sliced to generate the aerodynamic loads data for the CSD 
code, this information is actually passed to the CSD code by another hie; 
the [project_rootname] .sectional_forces and [project_rootname] 
_slice.dat hies are not used. 

8. Although the slicing process will work for multi-element airfoils, at this 
time the computation of the leading edge and trailing edge is only done 
for the entire section, not each element individually. 



0.4 0.45 0.5 


X 

Figure B3: A sliced section, zoomed in to the leading edge region. 
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B.4.28 &;overset data 


This namelist specifies information for overset grid simulations. The overset 
option may be used with either static or dynamic meshes. In either case, 
an initial overset connectivity file, corresponding to the configuration at t=0, 
must be provided. Connectivity files must be in the SUGGAR++ ‘dci’ format, 
or, if using the dci_io option (see below), in the FUN3D ‘dcif’ format. A 
conversion utility (utils/dci_to_dcif ) is provided to convert from the dci 
format to the dcif format. The initial overset connectivity file must be named 
[project] .dci (or [project] .dcif if using the dci_io option). For dynamic 
meshes, the user may elect to provide precomputed connectivity files for each 
time step, in which case the files must be named [project] l.dci for time step 
1 at t=At, [project] 2. dci for time step 2 at t=2At, and so on. The naming 
convention is the same when using the dci_io option, except the file extension 
is .dcif rather than .dci. 


&overset_data 


overset_f lag 

= 

•false . 

dci_on_the_f ly 

= 

•false . 

dci_period 

= 

huge(l) 

reset_dci_period 

= 

•false . 

dci_freq 

= 

1 

dci_dir 

= 

1 1 

reuse_existing_dci 

= 

•false . 

skip_dci_output 

= 

•false . 

dci_io 

= 

•false . 

dci_io_nproc 

= 

1 

use_imesh_constraiiit 

= 

. true . 


/ 


oversetAlag = .false. 

When .true., overset mesh capability is enabled. 
dci_on_the_f ly = .false. 

This controls whether overset connectivity is computed as the grid moves, 
or whether overset connectivity has been pre-computed for each grid 
position and is available to read in. Ignored if overset _f lag = .false, 
and overset_rotor = .false, in the &rotor_data namelist. 

dci.period = huge(l) 

This controls the period (in terms of timesteps) at which the dci counter 
is reset. At time step dci_period+l, the flow solver will read overset 
data from the dci file [project] l.dci, corresponding to time step 1 at 
t=At. (Note: if dci_io = .true., the corresponding file name would 
be [project] 1. dcif). For example, if the simulation involves rotation 
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through 360 degrees with a time step corresponding to 1 degree per 
step, set dci_period = 360, and, if the user is providing precomputed 
dci hies, the hnal one provided would be named [project] 360. dci and 
would correspond to the 360 degree position. If instead the same 360 
degree rotation was run with 0.5 degrees per step, set dci.period = 720 
and the hnal dci hie would be [pro j ect] 720. dci, again corresponding to 
the 360 degree position. When using the dci_on_the_f ly option, connec- 
tivity hies are computed and written for the hrst dci .period timesteps, 
after which the code begins reading and reusing the connectivity hies. 
The default value implies that the motion is not periodic and therefore 
the dci counter is never reset. Ignored if overset_flag = .false, and 
overset .rotor = .false, in the ferotor.data namelist. 

reset_dci_period = .false. 

When .true., allows dci.period to be reset to a diherent value for 
restarting with a diherent time step. 

dci.freq = 1 

This controls how frequently the dci data is updated, either by compu- 
tation within the how solver, or by reading a new dci hie. Dci data is 
updated every dci_freq time steps. 

dci.dir = ’ 

This is the directory where dci hies are located. Note: A trailing for- 
ward slash (/) is automatically added and should not be included in the 
directory name. 

reuse_existing_dci = .false. 

When .true., allows the computation of dci data to be skipped if a dci 
hie for the current time step already exists. This option is typically used 
in conjunction with dci.period, so that dci hies are computed on the hy 
for the hrst dci.period time steps, and then hies are reused for all subse- 
quent periods of grid motion, without having to change dci_on_the_f ly 
in between. Ignored if dci_on_the_f ly = .false.. 

skip_dci_output = .false. 

When .true., the solver will not save the dci data to a hie. Ignored if 
dci_on_the_f ly = .false.. 

dci_io = .false. 

When .true., dci hies are read from disk with a dedicated rank (proces- 
sor) to help mask communication with computation. 
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dci_io_nproc = 1 

When dci_io = .true., this specihes the number of ranks to use for 
loading of dci hies. 

use_imesh_constraint = .true. 

When .true., the imesh value is taken into account when partitioning. 
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B.4.29 &rotor data 


This namelist controls high-level rotor simulation settings. Eventually, this 
namelist may subsume rot or. input. 

&rotor_data 

comprehensive_rotor_coupling = 'none' 
overset_rotor = .false. 

/ 


comprehensive_rotor_coupling = 'none' 

This controls whether the code is to be coupled to a rotorcraft compre- 
hensive code, and if so, which one. 

'none' not coupled. 

'camrad' coupled to CAMRAD-II. 

'rcas' loosely coupled to RCAS. 

'rcas_tight' tightly coupled to RCAS. 

'fsi' tightly coupled to DYMORE. 

overset_rotor = .false. 

This controls whether overset meshes are used for moving rotor simula- 
tions. When .true., the rotor motion is governed by the rotor. input 
hie. 
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B.4.30 &adapt metric construction 


This namelist controls how the metric is formed for metric-based mesh adap- 
tation. More details on grid adaptation can be obtained in section 8. 

&adapt_metric_construction 


adapt _he s s i an_key 

= 

' mach ' 

adapt _hessian_method 

= 

' Isq' 

adapt _max_anisotropy 

= 

l.OeS 

adapt _max_edge_growth 

= 

2.0 

adapt _max_edge_length 

= 

-1.0 

adapt _min_edge_length 

= 

-1.0 

adapt _output_tolerance 

= 

-0.5 

adapt _complexity 

= 

-1.0 

adapt _gradat ion 

= 

-1.0 

adapt _error_estimat ion 

= 

' embed ' 

adapt _st at istics 

= 

'median' 

adapt _exponent 

= 

0.2 

adapt _f eature_s cal ar_key 

= 

' density 

adapt _feature_s cal ar_form 

= 

' delta' 

adapt _feature_length_exp 

= 

0.5 

adapt _inter sect _metric_in_time 

= 

. false . 

adapt_metr ic_f rom_f ile 

= 

1 1 

adapt _export_metric 

= 

. false . 

adapt_twod 

= 

. false . 

adapt_verbose 

= 

. false . 

adapt _export_feature_scalar_key 

= 

' none ' 

adapt _visualize_metric 

= 

' none ' 

adapt _ current _h_met hod 

= 

' edge ' 

adapt _ current _h_gr adat ion 

= 

1.5 


adapt Ties sian_key = 'mach’ 

This variable is used to define anisotropic Hessian, 

' mach ' is Mach number. 

'pressure’ is pressure. 

' entropy ’ is entropy. 

'temp’ is temperature. 

'density’ is density. 

' vorticity-magnitude ’ is the magnitude of the vorticity vector. 
adapt_hessian_method = ’Isq’ 

This is the mathematical method used to recover the Hessian, 
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' Isq’ applies a least-square gradient calculation twice. First it computes 
gradients via least-squares. Then the Hessian is computed by a second 
application of least-squares to the reconstructed gradient. 

'green’ use a Green variational approach, see Alauzet and Loseille [52] 
for details. 

' kexact ’ reconstructs the Hessian with a k-exact approach. See Barth 
[53] for details. 

'grad’ is volume-averaged element-based gradients, applied twice. 

'mesh’ implies the metric of the current grid for use in testing grid 
adaptation mechanics or maintaining the current anisotropy. 

adapt Jiax_anisotropy = 1.0e6 

This is the upper limit of the largest to smallest spacing in the metric, 
adapt _max_edge .growth = 2.0 

This is the amount of coarsening that will be allowed by the scalar term 
of feature-based adaptation. It is not used by adjoint-based adaptation. 

adapt jnax_edge_length = -1.0 

This sets a maximum allowable spacing of the metric. It is a grid and 
problem dependent value and should be expressed in grid units. A neg- 
ative value is unlimited. 

adapt jnin_edge_length = -1.0 

This sets a minimum allowable spacing of the metric. It is a grid/problem 
dependent value and should be expressed in grid units. A negative value 
is unlimited. 

adapt_output_tolerance = -0.5 

This is the error request for output-based adaptation and the scaling of 
the scalar term for feature-based adaptation. Feature-based adaptation 
requires a positive number. Output-based adaptation can be negative 
to indicate a relative error reduction or positive to indicate an absolute 
error request. It is difficult to choose a good value for this tolerance, see 
adapt.complexity for a more intuitive way to request the adapted grid 
size. 

adapt.complexity = -1.0 

This is the target complexity for the metric. It is intended to allow a 
user specihcation of the number of nodes in the adapted grid. There is 
a difference between the requested complexity and the number of nodes 
in the adapted grid that is a function of grid size. This is because the 
requested complexity is a continuous measure, but the metric is discrete. 


228 



Also, the adaptation mechanics produce a grid that is near but does not 
exactly match the metric. Adjust the requested complexity manually to 
obtain the desired grid size if the grid is smaller or larger than expected. 

adapt .gradation = -1.0 

This is the allowable gradation of spacing between adjacent metric ten- 
sors. [54] A positive value activates gradation control, which should have 
parameter in the range [1.1 — 2.0]. A negative value deactivates this 
option. A smaller value producing a more gradual spatial variation of 
the spacing request (1.0 would be no variation). 

adapt_error_estimation = 'embed' 

This selects the method used for error estimation for output-based adap- 
tation, 

' embed ' uses a uniformly rehned grid and interpolated solution to esti- 
mate the output error. [55] 

'single' uses the current grid and reconstructed solution to estimate 
the output error. Uses much less memory, but does not provide an 
improved estimate of the functional. [29] 

' opt-goal ' is the optimal goal-oriented metric. [56] It requires the 
namelist option adapt.complexity to be set. 

adapt .statistics = 'median' 

This selects the method used for determining the error level to equidis- 
tribute, 

'median' uses the median of the error estimate to normalize the error 
before converting it to a new isotropic size request. This is useful when 
there are a few, extremely large error estimates that corrupt the average. 

' average ' uses the average of the error estimate to normalize the error 
before converting it to a new isotropic size request. This is provides 
better equidistribution when the error estimate is well behaved. 

adapt .exponent = 0.2 

This is the exponent on error estimate to map local error to a change 
in grid spacing. It is based on an a priori spatial error convergence 
estimate. [55] 

adapt.f eature.scalar.key = 'density' 

This is the “key” flow variable (feature) on which to adapt for feature- 
based adaptation, 

'mach' is Mach number. 
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'pressure’ is pressure. 

' entropy ’ is entropy. 

'temp’ is temperature. 

'density’ is density. 

' vorticity-magnitude ’ is the magnitude of the vorticity vector. 
adapt_f eature_scalar_f orm = ’delta’ 

This is the method to calculate feature-based rehnement indicator from 
the adapt_f eature_scalar_key scalar field. The following terms are 
computed for each edge in the grid and the nodal adaptation intensity 
is the maximum for all incident edges. The edge terms are, 

' delta’ is the jump in the key across the edge. 

' delta-1 ’ is the jump the key across the edge times the edge length to 
the adapt_f eature_length_exp power. 

'average-1’ is the average key of the two nodes of an edge times the 
edge length. 

' ratio ’ is the ratio of the largest to the smallest key at the edge nodes, 
'max’ is the largest key at the nodes of the edge. 

' none ’ will not use scalar term. It is uses the Hessian only. 
adapt_f eature_length_exp = 0.5 

This is the exponent for use with adapt_f eature_scalar_f orm = ’ delta-1 ’ . 
adapt_intersect jnetric_in_time = .false. 

This will export a metric intersected over a window that includes each 
time step of the current run. It is used for hxed-point adaptation of 
time-accurate simulations. [56] 

adapt Jietric_from_file = ’ ’ 

This reads the metric from this hie instead of computing it when it is 
blank. 

adapt_export_metric = .false. 

This exports the metric for external grid adaptation tools. 
adapt_twod = .false. 

When .true., compute a 2D metric for a one cell wide 3D grid. This 
is required when a 2D adaptation method is selected but the grid is 
actually a one cell wide 3D grid, because the adjoint does not have a 2D 
specihc mode. 
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adapt_verbose = .false. 

When .true., this option reports more information during the error es- 
timation process. This can be helpful for hnding the source of NaNs. 

adapt_export_f eature_scalar_key = ’none' 

This is the format to export the feature scalar key for visualization, 

'none’ will not export. 

' cgns ’ is CGNS format, requires Fun3D to be conhgured with a CGNS 
library. This format already includes x, y, and z. Set these variables to 
.false, to avoid duplication. 

'fvuns’ is FieldView G-binary (Fortran stream) format. This format 
already includes x, y, and z. Set these variables to .false, to avoid 
duplication. 

'VTK’ is legacy VTK format. 

' CSV’ is a comma separated value format. 

'tec’ is a single image ASGII tecplot format. 

'raw.ascii’ is a single image raw ASGII space separated format 
adapt_visualize_metric = ’none’ 

This is the format to export the metric for visualization, 

'none’ will not export. 

' cgns ’ is GGNS format, requires Fun 3D to be conhgured with a GGNS 
library. 

'fvuns’ is FieldView G-binary (Fortran stream) format. 

'VTK’ is legacy VTK format. 

' CSV’ is a comma separated value format. 

'raw.ascii’ is a single image raw ASGII space separated format, 
adapt .current _h_method = ’edge’ 

This is the method to estimate the current spacing of the grid, 

' edge ’ will use the shortest incident edge at a node. 

'implied’ will use the largest eigenvalue of adjacent element implied 
metrics. 

adapt .current _h_gradat ion = 1.5 

This limits the gradation of the current spacing estimate by requiring it 
to be larger than this ratio of its neighbor’s spacing estimate. 


231 



B.4.31 &adapt mechanics 

This namelist contains variables that control how grid adaptation is per- 
formed. More details on general metric-based grid adaptation can be ob- 
tained in section 8. This namelist also contains variables to control specialized 
line adaptation adapt_library = ’line' and shock htting line adaptation 
adapt_library = ’sfline’. 

Variables with the ladapt_ prehx control line adaptation and variables 
with a sfline. prehx control shock htting line adaptation. These specialized 
ID adaptation methods originated in the LAURA code and have a number of 
requirements that are described in the LAURA User’s Manual. [57] The grid 
origin must be structured and all nodes assigned to a unique line. All lines 
must have the same number of nodes. The outer boundary (opposite solid 
walls) can be moved in or out to align with a developing bow shock and the 
distribution of points across the boundary layer can be adjusted to recover a 
target cell Reynolds number. If the grid has prisms grown oh a solid surfaces 
then the distribution of prism heights can be adjusted to recover a target cell 
Reynolds number at the wall while retaining the the original spacing at the 
top of the prism stack. 

Variable names beginning with sfline. control how shock htting meshes 
are adapted. Currently the shock htting is only available with line adaptation 
which is engaged by specifying adapt.library = ’sfline’. The variables 
ladapt_re_cell, ladapt.epO.grd, ladapt_fstr, and ladapt_g_limiter are 
also active with shock htting. 


&adapt_mechanics 


adapt _libr ary 

= 

' refine 

adapt_project 

= 

1 1 

adapt _freezebl 

= 

-1.0 

adapt_cycles 

= 

2 

adapt _bamg_comm and 

= 

'bamg' 

adapt _bamg_geometry_format 

= 

' amdba ' 

ladapt_f sh 

= 

0.8 

ladapt_f str 

= 

0.75 

ladapt_f ctr jmp 

= 

1.05 

ladapt_re_cell 

= 

1. 

ladapt_beta_grd 

= 

0. 

ladapt_epO_grd 

= 

0. 

ladapt_max_di stance 

= 

l.e+06 

ladapt_jumpf lag 

= 

2 

ladapt_f req 

= 

0 

ladapt_max 

= 

1000 

ladapt_g_limiter 

= 

0. 

sf adapt _fsbuffr 

= 

3 

sf adapt_ceqinc 

= 

0.5 
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sf adapt_shkdtct = l.Oe-01 

sf adapt_f sf racO = l.Oe+00 

sf adapt_f sfraci = l.Oe-01 

/ 

adapt .library = ’refine/one’ 

This is the adaptation library to call from Fun 3D. The options are, 

'refine/one’ is the rehne tetrahedral metric-based adaptation library. 
See Park [29] for a detailed description. 

'refine/two’ is a version of the rehne adaptation library that is still 
undergoing development. It is based on original version of rehne with 
some ideas from Michal and Krakos. [58] 

'meshsim' is the Simmetrix MeshSim™ adaptation library. 

' bamg ’ is the BAMG [4] 2D metric-based adaptation library. The metric 
and solution hies will be exported and the BAMG executable will be run 
in the ../Flow directory. 

'line' is line-based adaptation [57] for structured grids. 

' sfline' is shock-htting line-based adaptation for structured grids. 

' interpolate’ will linearly interpolate the project_rootname solution 
to an existing adapt.project grid without adaptation using the ap- 
proach of Shenoy. [59] 

adapt.project = ’ ’ 

This is the project name for exporting the adapted grid and solution. An 
empty string appends _R to the project_rootname from the feproject 
namelist. 

adapt_freezebl = -1.0 

This prevents modihcation of the grid within this distance of solid wall 
boundaries. It is used to to preserve an existing boundary layer grid 
structure. A negative value does not freeze and the distance is specihed 
in grid units. A distance that equates to a y~^ of approximately 300, 
the middle of the log-layer is recommended. It is described by Park and 
Garlson. [60] 

adapt.cycles = 2 

This is the number of adaptation passes. It is only used for adapt .library 
= ’ \ref ine/ one ’ . Ghoosing more cycles will produce a grid that better 
matches the metric, but can increase the time required for adaptation. 

adapt _bamg_command = ’bamg’ 

This the the system command to execute BAMG. It may include the full 
path or command line arguments. 
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adapt_bamg_geometry .format = ’amdba’ 

BAMG geometry file format 

' amdba’ specifies -b [project_rootname] .ambda as the BAMG geome- 
try source. This will spline current boundary nodes to form the geometry 
of the domain boundary. It is approximate, but less likely to fail than 
.msh hie boundary reconstruction. 

'msh’ specihes -b [project_rootname] .msh as the BAMG geometry 
source. This will access the original geometry .msh hie to dehne the 
domain boundary, but BAMG may have problems with boundary recon- 
struction. 

ladapt_fsh = 0.8 

This is the fraction of the distance between the body and the opposing 
boundary along a line of nodes where the captured shock is situated. 

ladapt_fstr = 0.75 

This is the fraction of edges along a line that are intended to resolve the 
boundary layer. 

ladapt_f ctrjmp = 1.05 

This is the property ratio used to detect the shock when marching from 
the freestream toward the body. It is assumed the how above the shock 
is uniform and the property ratios across edges along the line remain 
equal to one until the shock is encountered. 

ladapt_re_cell = 1. 

This is the target cell Reynolds number based on the speed of sound 
used to dehne the edge length An of the hrst edge leaving the wall. 
rcceii = pAnc/n- 

ladapt.beta.grd = 0. 

This is an exponential grid distribution parameter. Any value greater 
than 1 will override adaptation. If it is used to override adaptation to 
local how, the recommended value is 1.15. 

Iadapt_ep0_grd = 0. 

This is a grid clustering factor to pull nodes into the captured shock. 
A minimum value of 0 produces no clustering. A maximum value of 
6.25 produces greatest clustering. Larger values can produce negative 
volumes. 

ladapt jnax.distance = l.e+06 

This is the maximum distance in grid units the outer boundary can be 
moved away from the body. This parameter is useful when adapting to 
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the shock in the wake, where the adapting grid may become excessively 
skewed. This value then effectively dehnes the maximum length of the 
wake domain. 

1 adapt _jumpf lag = 2 

This is an integer flag used to select the method of shock detection, 

' 0 ' is no movement of outer boundary. Resolution in the boundary layer 
is adjusted to recover target re_cell. 

' 1 ' uses pressure as sensing parameter. 

' 2 ' uses density as sensing parameter. 

' 3 ' uses temperature as sensing parameter. 

'4' scales all edges along the line by a factor equal to ladapt_f ctrjmp. 
ladapt_freq = 0 

This is the number of relaxation steps between calls to line adaptation. 
The value 0 prevents line adaptation. 

ladaptanax = 1000 

This is the maximum number of calls to line adaptation permitted. 
ladapt_g_limiter = 0. 

This parameter insures a minimum mesh size does not get too big on a 
line and cause local skewing. It must be a positive number to engage. 

sf adapt _fsbuffr = 3 

This is the number of buffer nodes between the freestream boundary and 
the htted shock. Zero buffer nodes make the freestream boundary the 
shock htting surface, three buffer nodes moves the shock htting surface 
three nodes into the interior of the computational domain relative to the 
freestream boundary. 

sf adapt_ceqinc = 0.5 

This is the shock fitting compatibility equation influence coefficient. A 
value of 0.0 means that shock htting is controlled by the continuity equal 
to the compatibility equation, a value of 1.0 means that the shock htting 
is controlled by momentum equation compatibility equal to the compat- 
ibility equation, and a value of 0.5 means that shock htting is equally 
controlled by the continuity and momentum compatibility equations. 

sf adapt_shkdtct = l.Oe-01 

This is the shock htting shock-boundary interaction detector coefficient. 
This parameter controls when the shock is considered to be interacting 
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with the shock fitting boundary nodes and determines when the bound- 
ary begins to be htted to the shock. The value is one minus the local 
relative density jump below which the shock is not considered to be in- 
teracting with the boundary. Increasing this parameter decreases the 
sensitivity of the sensor and decreasing this parameter increases the sen- 
sitivity of the sensor. 

sf adapt _fsfracO = l.Oe+00 

This is the shock htting initial freestream velocity boundary velocity frac- 
tion. When the bow shock has not yet reached the freestream boundary, 
the shock fitting equations are not valid. However, the code allows the 
freestream boundary to initially move towards the body at some fraction 
of the freestream boundary velocity. A value of 0.0 freezes the freestream 
boundary until the shock reaches it, a value of 1.0 moves the freestream 
boundary at the freestream velocity until the shock reaches it, and a 
value in the range (0.0, 1.0) moves the freestream boundary towards the 
body at sf adapt _fsfracO*freestreamtotal velocity. 

sf adapt_f sfraci = l.Oe-01 

This is the shock fitting interaction freestream velocity boundary veloc- 
ity fraction. When the bow shock has been determined to be interact- 
ing with the freestream boundary, the shock htting equations are not 
valid all along the shock. However, the code allows the initial interac- 
tion speed of the shock with the freestream boundary to be scaled back 
at some fraction of the freestream boundary and/or shock velocity. A 
value of 0.1 constrains the freestream boundary to move at a fraction 
of the freestream velocity and a value in the range (0.0, 1.0) moves the 
freestream boundary towards/away from the body at freestream total 
velocity* sf adapt _f sf rac i . 
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B.4.32 &massoud output 

This namelist controls the output of hies for interaction with the MDO pack- 
ages (e.g., design, aeroelastics). In a design setting, these hies contain the 
information necessary to parameterize the surface grid(s). The command- 
line option --write_aero_loads_to_f ile is required to output the aeroelas- 
tics hie [project_rootname] _ddfdrive_bodyN.dat and the command line op- 
tion --write_massoud_f ile is required to output the design parameterization 
hie [project_rootnamel_massoud_bodyN.dat for each of the N body groups 
present. 

&mas s oud_output 


n_bodies 

= 

0 




nbndry ( : ) 

= 

0 




boundary_list ( : ) 

= 

1 1 




massoud_output_f req 

= 

-1 




massoud_f ile_f ormat 

= 

' ascii ' 



massoud_use_initial_coords 

= 

. false . 



aero_loads_output_freq 

= 

-1 




aero_loads_file_f ormat 

= 

' ascii ' 



include_time_inf 0 

= 

. true . 



aero_loads_use_initial_coords 

= 

. false . 



aero_loads_dynamic_pressure 

= 

1.0 




output_transf orm(l , 1 : 4) 

= 

1.0, 

0.0, 

0.0, 

0.0 

output_transform(2, 1 :4) 

= 

0.0, 

1.0, 

0.0, 

0.0 

output_transform(3, 1 :4) 

= 

0.0, 

0.0, 

1.0, 

0.0 

output_transf orm(4, 1 : 4) 

= 

0.0, 

0.0, 

0.0, 

1.0 

output _scale_f actor 

= 

1.0 




input_transf orm(l , 1 :4) 

= 

1.0, 

0.0, 

0.0, 

0.0 

input_transform(2, 1 :4) 

= 

0.0, 

1.0, 

0.0, 

0.0 

input_transform(3, 1 :4) 

= 

0.0, 

0.0, 

1.0, 

0.0 

input_transf orm(4, 1 :4) 

= 

0.0, 

0.0, 

0.0, 

1.0 

input _scale_f actor 

= 

1.0 





/ 


n_bodies = 0 

This is the number of user-dehned bodies. For moving-grid cases, these 
bodies are typically the same as those dehned as moving bodies, but that 
need not be the case. 

nbndry ( : ) =0 

This is the number of boundary patches listed for a given body, 
boundary.list ( : ) = ’’ 

This is a list of boundary patch numbers for a given body. Commas and 
dashes can be used to specify ranges, i.e., ’1,2, 5-7’ . 
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massoud_output_freq = -1 

This is the iteration frequency of massoud output, where the special 
value -1 corresponds to once at the end of a successful run. 

massoud_f ile_f ormat = ^ ascii' 

This is the format of the massoud hie; the alternate choice is ’ stream' 
(C binary). 

' ascii ' is ASCII hie format 
' stream' is Fortran stream (C binary) format 

massoud_use_initial_coords = .false. 

Write the massoud hie for the x, y, z surface coordinates at t=0. Other- 
wise, use current x, y, 2 ; surface coordinates. 

aero_loads_output_freq = -1 

This is the iteration frequency of aerodynamic loads output, where the 
special value -1 corresponds to once at the end of a successful run. 

aero_loads_file_f ormat = 'ascii' 

This is the format of the aerodynamic loads hie; the alternate choice is 
'stream' (C binary). 

' ascii ' is ASCII hie format 

' stream' is Fortran stream (C binary) format 

include_time_inf o = .true. 

Write simulation time and strand info to ASCII Tecplot™ hle(s). Includ- 
ing time info in the hies makes animation within Tecplot™ very simple. 

aero_loads_use_initial_coords = .false. 

Write the current aerodynamic loads mapped to the x, y, 2 : surface coor- 
dinates at t=0. Otherwise, use current x, y, 2 : surface coordinates. This 
option is only relevant if the grid is moved or changed during the solution 
process. 

aero_loads_dynamic_pressure = 1.0 

The dynamic pressure used to convert force coefficients into forces; the 
default value leaves the output in coefficient form. Note that the input 
variable output _scale_f actor separately handles scaling of coordinate 
values, so care must be exercised to insure appropriate dimensional forces 
if both are used in combination. 
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output.transf orm(l , 1 :4) = 1.0, 0.0, 0.0, 0.0 

This is a user-specified transform matrix to allow output of aero loads 
in a custom coordinate system; typically used to output aero loads in 
an FEM/CSD coordinate system that differs from the CFD coordinate 
system. Note, at this point in time, this transform is applied to ALL 
bodies that are defined in this namelist. Note: the transform matrix 
should NOT include a scaling factor (e.g. inches to meters); any required 
scale factor is input separately. 

output_scale_f actor = 1.0 

Allows a scaling of the output x,y,z coordinates (e.g. meters to inches). 
Scaling is applied as a multiplicative factor. 

input_transf orm(l , 1 : 4) = 1.0, 0.0, 0.0, 0.0 

This is a user-specified transform matrix to allow input of a new surface 
mesh that is defined in a custom coordinate system; typically used to 
read in a displaced surface defined in an FEM/CSD coordinate for use in 
the CFD coordinate system. Note, at this point in time, this transform 
is applied to ALL bodies that are defined in this namelist. Note: the 
transform matrix should NOT include a scaling factor (e.g. inches to 
meters); any required scale factor is input separately. 

input _scale_f actor = 1.0 

Allows a scaling of the input x,y,z coordinates (e.g. inches to meters). 
Scaling is applied as a multiplicative factor. 
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B.4.33 &;sonic boom 


This namelist specifies how near-field pressures are extracted from Fun 3D 
for comparison to wind tunnel measurements, atmospheric propagation to the 
ground by another code, or for boom related adjoint cost functions. When 
nsignals is greater than zero, the pressure signature is output as a Tecplot™ 
file. The number of points in this output file is determined by the number of 
element faces intersected by each user-specified ray, and will span the x-extent 
of the entire mesh at that ray location. 

The rays are rotated about (x_cor,z_cor) by anglemf ^attack when the 
variable rotate_ray_by_angle_of ^attack is true. 

This namelist is also used with the sonic boom adjoint cost functions 
boom_targ (section 9.2.6) and sboom (section 9.2.7). To form the cost func- 
tion the ../rubber. data file is required for the flow and adjoint solvers. See 
section 6.3 for details on the minimum inputs required for specifying the ad- 
joint cost function. To compute the value of the objective function in the flow 
solver, the — design_run command line option is required. 


&sonic_boom 



nsignals 

= 

0 

y_ray( : ) 

= 

0.001 

z_ray ( : ) 

= 

0.0 

x_cor 

= 

0.0 

z_cor 

= 

0.0 

rotate_ray_by_angle_of _attack 

= 

. true . 

npoints 

= 

1000 

ray_x_limit .method 

= 

' local 

x_lower_bound 

= 

-l.e20 

x_upper_bound 

= 

l.e20 

dp.pinf 

= 

. true . 

p.pinf 

= 

. false 

weight 

= 

. false 


/ 


nsignals = 0 

This is the total number of signal rays. 
y_ray(:) = 0.001 

This is the y value of each ray before anglemf ^attack rotation. It is 
dimensioned 1 to nsignals. 

z_ray(:) = 0.0 

This is the z value of each ray before angle.of .attack rotation. It is 
dimensioned 1 to nsignals. 
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x_cor = 0.0 

This is the x center of angle.of .attack rotation. 
z_cor = 0.0 

This is the z center of angle.of .attack rotation 
rotate.ray .by .angle.of .attack = .true. 

When .true., this will rotate the rays by angle.of .attack about x.cor 
and z.cor. 
npoints = 1000 

This is the nominal number of points in each ray that is used to construct 
the cost function. Any points lying outside the domain will be ignored. 
The points are linearly spaced between the lower and upper bound of x. 

ray_x_limitunethod = ’local’ 

This is the method used to determine the x-direction start and end of 
the ray when forming the objective function. If x.lower.bound and/or 
x.upper.bound is specified, then ray.x.limit unethod must be set to 
’explicit’. 

' local ’ sets each ray limit independently by computing the x min and 
X max of all grid cells intersected by the ray. 

'explicit’ explicitly sets the x min and x max of all rays with the 
x.lower.bound and x.upper.bound namelist variables. Only valid for 
adjoint cost function boom.targ. 

x.lower.bound = -l.e20 

This is the explicit x lower bound for ray.x.limit unethod=’ explicit ’ 
in the cost function dehnition. 
x.upper.bound = l.e20 

This is the explicit x upper bound for ray.x.limit jnethod=’ explicit ’ 
in the cost function dehnition. 
dp.pinf = .true. 

When .true., this will include normalized delta pressure {p — Poo) /Voo in 
tecplot output. 

p.pinf = .false. 

When .true., this will include normalized pressure {p)/poo in tecplot 
output. 

weight = .false. 

When .true., this will include a weight of one in tecplot output for use 
in setting up a near-body target pressure design. 
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B.4.34 &;sboom 

This namelist contains variables that specify the inputs required to execute 
the sBOOM library. See section 9.2.7 for details. 


fesboom 

alt 

= 

45000.0 

lig 

= 

0.0 

headangle 

= 

0.0 

climbangle 

= 

0.0 

dmdt 

= 

0.0 

turnrate 

= 

0.0 

climbrate 

= 

0.0 

rs 

= 

500.0 

signum 

= 

10000 

zeronum 

= 

1200 

tol2 

= 

l.e-6 

nonlinear 

= 

1 

thermoviscous 

= 

1 

relaxation 

= 

1 

initialtimestep 

= 

0.01 

ref 1 

= 

1.9 

out flag 

= 

0 

numouts 

= 

1000 

tol 

= 

0.005 

inputininches 

= 

0 

ad j mode 

= 

1 

runmode 

= 

1 

objmode 

= 

1 

nazimuths 

= 

1 

phi(:) 

= 

0.0 

targetdbas ( : ) 

= 

56.0 

createtarget 

= 

0 

lowerbound 

= 

-1000.0 

upperbound 

= 

-1000.0 

lappass 

= 

500 

target _numpts ( : ) 

= 

0 

target_xx( : , : ) 

= 

0.0 

target_dpress ( : , 

:) = 

0.0 

tflag 

= 

0 

ntalt 

= 

0 

ztalt ( : ) 

= 

0.0 

talt ( : ) 

= 

0.0 

windf lag 

= 

0 

nwindx 

= 

0 

zwindxC : ) 

= 

0.0 
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windx ( : ) 

= 

0.0 

nwindy 

= 

0 

zwindy ( : ) 

= 

0.0 

windy ( : ) 

= 

0.0 

rf lag 

= 

0 

nhalt 

= 

0 

zrh( : ) 

= 

0.0 

rh(:) 

= 

0.0 

bodylen 

= 

127.0 

reg 

= 

1 

CD 

1 

regr 

= 

1 

CD 

1 

Ibd 

= 

0.99 

ubd 

= 

1.0 


alt = 45000.0 

This is the cruise altitude of the full-scale vehicle in feet. 
hg = 0.0 

This is the height of the ground in feet, 
headangle = 0.0 

This is the vehicle heading angle in degrees. A 180 heading would mean 
away from the x-axis, a 90 heading would mean away from the y-axis. 
This option is only relevant when winds are specihed. 

climbangle = 0.0 

The is the vehicle climb angle in degrees. 

dmdt = 0.0 

This is the acceleration of the vehicle in 1/second (Mach number per 
second). 

turnrate = 0.0 

This is the turning rate of the vehicle in degrees per second. 
climbrate = 0.0 

This is the climb rate of the vehicle in degrees per second. 
rs = 500.0 

This is the off-body distance in full-scale feet. This full-scale distance 
should match the location in grid units used to dehne y_ray and z_ray 
in &sonic_boom. 
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signum = 10000 

This is the number of points representing the off-body waveform for prop- 
agation. Increasing the number points reduces the discretization error 
of the Burgers equation and increase the execution time of sBOOM. 

zeronum = 1200 

This in the number of points used to zero pad the front part of the 
signature. These points are required to prevent the initial shock from 
propagating to the front of the Burgers equation domain and causing 
a numerical instability. The actual waveform will be sampled using 
(signum-zeronum) points. Typically, 10-20% of signum is required. 

tol2 = l.e-6 

This is the leading zero tolerance of the input waveform. It is used to 
truncate the initial portion of the off-body waveform before zero padding, 
where dp/p value are less than this number. 

nonlinear = 1 

This controls solution non-linearity, 

' 1 ' uses cumulative non-linearity. 

' 0 ' does not use cumulative non-linearity. 
thermoviscous = 1 

This controls the modeling of thermo-viscous absorption, 

' 1 ' uses cumulative thermo-viscous absorption. 

' 0 ' does not use thermo- viscous absorption. 
relaxation = 1 

This controls the modeling of molecular relaxation, 

' 1 ' uses cumulative molecular relaxation. 

' 0 ' does not use molecular relaxation, 
initialtimestep = 0.01 

Nondimensional initial step size for propagation. A smaller number pre- 
vents a multi-valued function, but increases execution time. If you re- 
ceive a discontinuity error, reduce this value. 

refl = 1.9 

This is the ground reflection factor used to scale ground signatures, 
outflag = 0 

This determines the format of the output. 
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' 0 ’ outputs delta pressure in psf as a function of time in ms. 

' 1 ' outputs delta pressure divided by freestream pressure as a function 
of X in feet. 

numouts = 1000 

This is the number of points requested in the ground signature. 
tol = 0.005 

This is the slope tolerance needed for removing zero paddings from the 
ground signatures. This allows signatures at different azimuthal angles 
to have the same time axis starting with the initial shock. 

inputininches = 0 

This is the units of the Fun 3D grid and geometry to scale the near held 
signature x for propagation, 

' 0' for Fun 3D grid units in feet. 

' for Fun 3D grid units in inches. 

' 2’ for Fun 3D grid units in meters. 

ad j mode = 1 

This is the sBOOM simulation mode, 

' 1 ' for a primal and adjoint simulation. 

' 0 ' for primal simulation only. 

runmode = 1 

This is the type of propagation and the class of cost function, 

' 1’ propagates near held dp/poo to ground and adjoint sensitivities of 
ground based metrics dehned by objmode. The target pressure is speci- 
hed with target_numpts, target.dpress, and target_xx. 

'0' reverse propagates near held dp/poo to compute equivalent area 
(when rs< (alt— hg)) and directly converts oh-body pressures to equiv- 
alent area (when rs> (alt— hg)). No ground signature or ground-based 
cost function is computed. See bodylen, reg, regr, Ibd, and ubd. The 
target area distribution is specihed with t argot _numpts, target.dpress, 
and target_xx. 

objmode = 1 

This is the cost function dehnition. The value of runmode changes its 
behavior as follows. 
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'1' for an A-weighted loudness target of / = {dBA — dBAtY when 
runmode=l and an equivalent area target / = ^[Ae{i) — Aetargetii)]"^ 

when runmode=0. 

‘2’ for an inverse pressure design objective of / = —p(t,i)]'^ 

when runmode=l and an equivalent area sum I = when 

runmode=0. 

' 3 ' for combined A-weighted loudness and inverse pressure design ob- 
jective of / = {dBA — 56.0)^ + Y^f=i[p{i) — p{t,i)]‘^ when runmode=l. 

'4' for an A-weighted loudness objective of / = dBA when runmode=l. 
nazimuths = 1 

This is the number of azimuths to propagate. The nazimuths must 
match nsignals in &sonic_boom. 

phi(:) = 0.0 

This is a nazimuths length vector of azimuthal locations in degrees, 
targetdbas ( : ) = 56.0 

This is the target {dBAt) at each azimuthal location when objmode=l. 
createtarget = 0 

This is the source of a ground target signature, 

' 0 ' for no ground target signature. 

‘ 1’ to internally create a ground target by Laplace smoothing. The 
smoothing is controlled by lowerbound, upperbound, and lappass. 

' 2 ' for a user specihed target. The target is defined by the targetmumpts, 
target_xx, and target_dpress variables. 

lowerbound = -1000.0 

When createtarget=l, this is the lower bound in time (milliseconds) 
after which the user wants to Laplace smooth the computed signature 
to form the target. When runmode=0, this dehnes the start of locations 
in X (feet) where any difference in equivalent area between actual and 
target equivalent areas will contribute to the cost functional. Outside 
these bounds, even if the equivalent area does not match the target, it 
does not contribute to the cost functional. 

upperbound = -1000.0 

When createtarget=l, this is the upper bound in time (milliseconds) 
before which the user wants to Laplace smooth the computed signature 
to form the target. When runmode=0, this defines the end of locations 
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in X (feet) where any difference in equivalent area between actual and 
target equivalent areas will contribute to the cost functional. Outside 
these bounds, even if the equivalent area does not match the target, it 
does not contribute to the cost functional. 

lappass = 500 

The number of Laplace smoothing passes to generate a target ground 
signature. A higher number increases the smoothness of the target. It 
is only used for createtarget=l. 

target_numpts( : ) = 0 

This is the number of points in the target_xx and target_dpress at 
each azimuth. It is used for runmode=l with objmode=2, 3 or runmode=0 
with objmode=l. 

target _xx( ) = 0.0 

This is the time (in milliseconds) of the target signature at each azimuth 
for runmode=l or x in feet for runmode=0. It is only used for some 
objective functions, see objmode. The first index is azimuthal location 
and the second index is the target signature point. 

target_dpress( : , : ) = 0.0 

This is the delta pressure (in psf) of the target signature at each az- 
imuth for runmode=l or the equivalent area target for runmode=0. It is 
only used for some objective functions, see objmode. The first index is 
azimuthal location and the second index is the target signature point. 

tflag = 0 

This controls the source for the atmospheric temperature distribution, 
'0' for the 1976 U.S. Standard Atmosphere temperature prohle. 

' 1 ’ for a temperature prohle specihed by ntalt, ztalt, and talt. 
ntalt = 0 

This is the number of ztalt altitude and talt temperature pairs to 
dehne the temperature prohle. 

ztalt(:) = 0.0 

This is ntalt length vector of altitudes (in meters) to specify an atmo- 
spheric temperature distribution. 

talt(:) = 0.0 

This is ntalt length vector of temperature (in Fahrenheit) to specify an 
atmospheric temperature distribution. 
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windflag = 0 

This controls the source for winds, 

' 0 ' for no winds. 

' 1 ' for a wind prohle specified by nwindx, windx, zwindx, nwindy, 
windy, and zwindy. 

nwindx = 0 

This is the number of zwindx altitude and windx x-wind pairs that dehne 
the wind prohle. 

zwindxC:) = 0.0 

This is a vector of length nwindx of altitude (in meters) to specify a wind 
prohle. 

windx(:) = 0.0 

This is a vector of length nwindx of x-wind speeds (in meters/sec) to 
specify a wind prohle. 

nwindy = 0 

This is the number of zwindy altitude and windy y-wind pairs that dehne 
the wind prohle. 

zwindyC:) = 0.0 

This is a vector of length nwindy of altitude (in meters) to specify a wind 
prohle. 

windyC:) = 0.0 

This is a vector of length nwindy of y-wind speeds (in meters/sec) to 
specify a wind prohle. 

rflag = 0 

This controls the source for the atmospheric humidity distribution, 

'0' for the 1976 U.S. Standard Atmosphere relative humidity prohle. 

' for a relative humidity prohle specihed by nhalt, zrh, and rh. 
nhalt = 0 

This is the number of zrh altitude and rh relative humidity pairs. 
zrh(:) = 0.0 

This is a vector of length nhalt of altitude (in meters) to specify a 
relative humidity prohle. 
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rh(:) = 0.0 


This is a vector of length nhalt of relative humidity (in percent) to 
specify a relative humidity prohle. 

bodylen = 127.0 

This is the aircraft body length in feet. It is only used for the adjoint of 
equivalent area matching, runmode=0 and adjmode=l. 

reg = l.e-4 

This is the thermo- viscous absorption regularization parameter. A smaller 
value could lead to an ill-posed reverse diffusion problem. A higher value 
increases error. Applicable only when rs< (alt— hg). It is only used for 
equivalent area, runmode=0. 

regr = l.e-4 

This is the molecular relaxation regularization parameter. A smaller 
value could lead to an ill-posed reverse diffusion problem. A higher 
value increases error. Applicable only when rs< (alt— hg). It is only 
used for equivalent area, runmode=0. 

Ibd = 0.99 

This is the under-deviation parameter for reversed equivalent area match- 
ing. Equivalent area deviations below a target are generally favorable to 
deviations above a target. Equivalent area matching cost functions and 
their sensitivities are only computed when the equivalent area is within 
the Ibd and ubd limits. It is only used for the adjoint of equivalent area 
matching, runmode=0 and adjmode=l. 

ubd = 1.0 

This is the over-deviation parameter for reversed equivalent area match- 
ing. Equivalent area deviations below a target are generally favorable to 
deviations above a target. Equivalent area matching cost functions and 
their sensitivities are only computed when the equivalent area is within 
the Ibd and ubd limits. It is only used for the adjoint of equivalent area 
matching, runmode=0 and adjmode=l. 


249 



B.4.35 ^equivalent area 

This namelist contains variables that specify the inputs associated with equiv- 
alent area-based sonic boom cost functions, which is described in section 9.2.8. 
The number and order of these inputs should match the equivalent area (Ae) 
functions appearing in ../rubber. data. 

&equivalent_area 


nf unctions 

= 0 

nplane ( : ) 

= 0 

global_scaling_f actor ( : ) 

= 1.0 

lif t_scaling_f actor ( : ) 

= 1.0 

of f _track_angle ( : ) 

= 0.0 

nfunctions = 0 



This is the total number of Ae functions, including functions used as 
objectives and constraints. 

nplaneC:) = 0 

This is the total number of cutting planes along x-axis for each Ae func- 
tion. 

global_scaling_f actor (: ) = 1.0 

This is the Ae(x) scaling factor for each Ae function. 

lif t_scaling_f actor (: ) = 1.0 

This is the Lift L(x) scaling factor for each Ae function, 
off _track_angle( : ) = 0.0 

This is the off-track angle in degrees for each Ae function. 
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B.4.36 &press box function 


This namelist contains variables that are required for the press_box function, 
which is described in section 9.2.9. The namelist requires the ../rubber. data 
file for the flow and adjoint solvers. See section 6.3 for details on the min- 
imum inputs required for specifying the adjoint cost function. To compute 
the functional in the flow solver, the --design_run command line option is 
required. 


&press_box_f unction 
integrand_type = 
gid 

xmin = 

xmax = 

ymin = 

ymax = 

zmin = 

zmax = 


0 

1 

-huged .0) 
huge (1 . 0) 
-huged .0) 
huge (1 . 0) 
-huged .0) 
huge (1 . 0) 


/ 


integrand.type = 0 

This integer indicates the functional form. 

' 0 Ms the volume integral of pressure squared inside the defined box. 

' 1 Ms the volume integral of w-momentum inside the defined box. 

' 2 Ms the volume integral of u-momentum inside the dehned box. 

' 3Ms the density at the global node with index gid. Not admissible for 
eqn.type = ’ incompressible h 

' 4Ms the time derivative of pressure at the global node with index gid. 

' 5Ms the time derivative of density at the global node with index gid. 
Not admissible for eqn.type = ’ incompressible h 

gid = 1 

This integer is a global grid point index to be used with integrand.type 
= 3-5. 

xmin = -huge (1.0) 

This real value defines the lower bound in the x-direction for the box 
that encloses the volume integral. 

xmax = huge (1.0) 

This real value dehnes the upper bound in the x-direction for the box 
that encloses the volume integral. 
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ymin = -huge (1.0) 

This real value defines the lower bound in the y-direction for the box 
that encloses the volume integral. 

ymax = huge (1.0) 

This real value defines the upper bound in the y-direction for the box 
that encloses the volume integral. 

zmin = -huge (1.0) 

This real value defines the lower bound in the z-direction for the box 
that encloses the volume integral. 

zmax = huge (1.0) 

This real value defines the upper bound in the z-direction for the box 
that encloses the volume integral. 
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B.4.37 &pstag function 


This namelist contains variables that are required for the pstag function, 
which is described in section 9.2.5. This namelist requires the ../rubber. data 
hie for the how and adjoint solvers. See section 6.3 for details on the min- 
imum inputs required for specifying the adjoint cost function. To compute 
the functional in the how solver, the --design_run command line option is 
required. 


&pstag_f unction 

slice_orientation = 1 

disk_radius = 1.0 

x_disk_origin = 0.0 

y_disk_origin = 0.0 

z_disk_origin = 0.0 

/ 

slice_orientation = 1 


This integer represents the orientation of the cutting plane. The accept- 
able values are 1 (x-plane), 2 (y-plane), and 3 (z-plane). 

disk_radius = 1.0 

This real value is the radius of the disk over which the function is to be 
evaluated. 

x_disk_origin = 0.0 

This real value is the x-coordinate of the origin of the disk. 
y_disk_origin = 0.0 

This real value is the y-coordinate of the origin of the disk. 
z_disk_origin = 0.0 

This real value is the z-coordinate of the origin of the disk. 
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B.4.38 Especial parameters 

This namelist specifies changes to the discretization to handle elements with 
large face angles. 

&special_parameters 
large_angle_f ix 
override_bc_limitation 
distance_chunk_size 

/ 

large_angle_f ix = ’off’ 

Grids with with elements that have adjacent face angles that approach 
180 degrees may result in a sudden onset of not a number (NaN). Grids 
produced by VGRID may contain these elements. 

'off’ uses all elements in viscous flux evaluation. This is a consistent 
viscous discretization. 

'on’ neglects viscous fluxes in cells containing angles between adjacent 
faces of 178 degrees or greater. This is an inconsistent discretization, 
but may allow the calculation of a solution on a grid that is not suitable 
for the consistent viscous discretization. 

override_bc_limitation = .false. 

Allow sensitivity analysis for cases with element-based boundary condi- 
tions. Users should contact Fun3D-Support@lists.nasa.gov to deter- 
mine if this option can be used for their simulation. 

distance_chunk_size = 20000000 

Size of the buffer surface boundary for use in the minimum distance 
determination required for turbulence models. 


= 'off 
= .false. 

= 20000000 
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B.4.39 &;vortex generator 

This namelist is used to specify parameters related to source terms designed 
to simulate the effects of vortex generators. 

&vortex_generator 
number_of _vgs 
configuration ( : ) 
boundary _pat chi ( : ) 
boundary _patch2 ( : ) 
planf orm_area( : ) 
height ( : ) 

calibration_constant ( : ) 
pointl_xcoord( : ) 
pointl_ycoord( : ) 
pointl_zcoord( : ) 
point2_xcoord( : ) 
point2_ycoord( : ) 
point2_zcoord( : ) 
point3_xcoord( : ) 
point3_ycoord( : ) 
point3_zcoord( : ) 
reverse_t ( : ) 
reverse_n( : ) 

/ 

number _of_vgs = 0 
Specihes the number of user-dehned vortex generators (max 1000). 

conf igurationC : ) = ’ area_and_height ’ 

Specihes the input conhguration for each vortex generator. If conhg- 
uration(i) is ’area_and_height’, then the ith vortex generator planform 
will be a symmetric trapezoid with the endpoints of its base dehned by 
the point 1 and point2 coordinate inputs in the namelist and its area 
and height dehned by the planform_area(i)and height(i) values. If con- 
hguration(i) is ’three_points’, then the ith vortex generator will have a 
triangular planform where the user must supply the coordinates of a 
third point dehning the oh-surface tip of the vortex generator geometry. 
In this case, the planform area and height are derived quantities based 
on the three input point locations. 

boundary.patchl ( : ) =0 

Specihes the boundary patch index for point 1 of the ith vortex generator. 
This patch will be used for projection of the pointl coordinates specihed. 


= 0 

= ' area_and_height ' 
= 0 
= 0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= 0.0 
= .false. 

= .false. 
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boundary_patch2( : ) = 0 

Specifies the boundary patch index for point2 of the ith vortex generator. 
This patch will be used for projection of the point2 coordinates specihed. 

planf orm_area( : ) = 0.0 

Specihes the intended planform area of the ith vortex generator. This 
input only required if conhguration = ’area_and_height’. 

heightC:) = 0.0 

Specihes the height of the ith vortex generator. This input only required 
if conhguration = ’area_and_height’. 

calibration_constant ( : ) = 0.0 

Specihes the calibration constant of the ith vortex generator, 
point l_xcoord( : ) = 0.0 

Specihes the x-coordinate of point 1 dehning the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary_patchl(i). 

pointl_ycoord( : ) = 0.0 

Specihes the y-coordinate of point 1 dehning the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary_patchl(i). 

pointl_zcoord( : ) = 0.0 

Specihes the z-coordinate of point 1 dehning the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary_patchl(i). 

point2_xcoord( : ) = 0.0 

Specihes the x-coordinate of point 2 dehning the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary_patch2(i). 

point2_ycoord( : ) = 0.0 

Specihes the y-coordinate of point 2 dehning the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary_patch2(i). 

point2_zcoord( : ) = 0.0 

Specihes the z-coordinate of point 2 dehning the ith vortex generator 
location. These coordinates need not be precise; the input coordinates 
will be projected onto boundary_patch2(i). 
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point3_xcoord( : ) = 0.0 

Specifies the x-coordinate of point 3 defining the ith vortex generator 
location. This input only required if conhguration = ’three_points’. 

point3_ycoord( : ) = 0.0 

Specihes the y-coordinate of point 3 dehning the ith vortex generator 
location. This input only required if conhguration = ’three_points’. 

point3_zcoord( : ) = 0.0 

Specihes the z-coordinate of point 3 dehning the ith vortex generator 
location. This input only required if conhguration = ’three_points’. 

reverse_t(:) = .false. 

Reverse the assumed direction of the unit vector t for the ith vortex 
generator. 

reverse_n(:) = .false. 

Reverse the assumed direction of the unit vector n for the ith vortex 
generator. 

Additional information on the use of vortex generator source terms 

The implementation of these source terms in Fun 3D is based on the heuristic 
model described in [61] and previous references cited therein. The approach 
avoids the need for resolving geometric details of vortex generator devices 
during mesh generation. Sufficient grid resolution may still be required to 
convect the simulated ehects of the vortex generator downstream as desired. 
The user must also provide a calibration constant for each simulated vortex 
generator. This value should be chosen carefully to produce the desired impact 
on the local flowheld. Vortex generator source terms currently may only be 
applied to static grid simulations. The source terms are treated fully implicit 
during the solution procedure. 

After developing the desired set of namelist inputs, it is useful to run the 
solver for a single iteration, requesting boundary output for (at least) the 
boundaries on which vortex generators are to be placed. The geometry for 
each vortex generator as determined by Fun 3D based on the namelist inputs 
will be provided in the Tecplot™ hie [project_rootname] _vg_geometry.dat. 
The user should visualize the placement of each vortex generator in relation 
to the boundary patches of the grid to ensure the desired placement. 

The user will also be provided with a Tecplot™ hie [project_rootname] 
_vg_vectors.dat. This hie contains the unit vectors b, t, and n according to 
the notation described in [61]. The user should visualize these vectors to ensure 
that they are oriented appropriately. The vector b is dehned uniquely by the 
local boundary orientation; however, Fun 3D attempts to infer the directions 
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of the vectors t and n based on the freestream direction. If the local flow 
direction is expected to be substantially different, these vectors may need to 
be manually reversed using the appropriate namelist inputs. 

If desired, the user may also plot the points at which the actual source 
terms will be computed by ‘scatter plotting’ the data contained in the Tec- 
plot™ hie [project_rootnamel_vg_source_locations.dat. These locations 
are determined by the intersections of the vortex generator geometries with 
edges in the grid. Source terms are computed at each of these locations then 
scattered to the residual values at either end of the intersecting edge. 

An example of the geometry features described above and the local howheld 
in the vicinity of simulated trapezoidal and triangular vortex generators near 
the leading edge of a wing is shown here. 




rho 



Unit vector n 


Figure B4: View of trapezoidal and triangular vortex generators placed near 
the leading edge of a wing geometry. The unit vectors b, t, and n are shown, 
as well as the points where the actual source terms will be computed. 
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B.5 moving body. input 


This namelist file is only used for time-dependent, moving grid cases to specify 
grid motion as a function of time. This hie must be used in conjunction 
with input variable moving_grid = .true, in the feglobal namelist of the 
funSd.nml input hie. See section 7 for an overview of moving grid capabilities. 

The grid-motion options in Fun 3D are fairly generally in order to handle 
a wide variety of applications. The basic approach is for the user to dehne one 
or more boundaries in the grid to be a ‘body’. Multiple bodies may be de- 
hned. Basic setup for these bodies is established using the febody .definitions 
namelist. A hierarchical relation may be established between multiple bodies 
to allow the motion of one body (a ‘child’) to follow the motion of another 
body (the ‘parent’). The top level of this hierarchy is the inertial reference 
frame, and all motion is ultimately referenced back to this inertial frame. Each 
body has its own reference frame, and the reference frames of all bodies are 
assumed to be coincident with the inertial reference frame at t=0. 

Having established the basic body definition(s), the user specifies a general 
descriptor (motion.driver) for the mechanism that will drive the motion of 
the body, and specifies how the mesh is to be moved - by rigid motion or 
by deformation (or both) - in response to the body motion. Note that mesh 
deformation requires more CPU time than rigid mesh motion, and is less ro- 
bust. Mesh deformation may lead to negative cell volumes, at which point the 
solution is terminated, while rigid motion will preserve positive cell volumes. 
Thus, rigid mesh motion should be favored over mesh deformation whenever 
possible. However, there are certain situations where only a deforming mesh 
is appropriate. For example if the body is aeroelastic, then the mesh must be 
deformed to fit the deformed body surface. In some situations the potential 
for a deforming mesh to encounter negative cell volumes can be mitigated by 
combining deformation with rigid motion. An example of this is the motion 
of elastic rotor blades, wherein the overall rotational motion of the blades is 
handled via rigid rotation, but the relatively smaller elastic deflection of the 
blades is handled via deformation. 

The motion.driver specihcation simply provides a notional mechanism for 
how the body is to be moved; details of this mechanism are then provided by 
one or more additional namelists. For example, if motion.driver = ‘forced' 
then details of how to move the body, perhaps by rotation with a given fre- 
quency and amplitude, are specified via the &f orcedjnotion namelist. Other 
options for motion.driver - and the required auxiliary namelists to specify 
the details - are given in the following sections. 

By default, boundary output from Fun 3D for visualization purposes (see 
section 5.3.1) is provided in the inertial frame. It is sometimes useful to have 
this output in a different reference frame, an ‘observer’ frame. For example, 
the observer frame might be one attached to a moving body. Specification of 
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an alternate observer frame is handled via the feobserver anotion namelist. 
See the following sections for descriptions of the namelists in this hie. 
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B.5.1 &body definitions 

This namelist specifies which mesh surfaces define the moving bodies. In 
general, each body may have a different motion. However, there are some 
fundamental constraints. For example, in a mesh with multiple bodies under- 
going different motions, either overset meshes or a deforming mesh would be 
required. Note that a deforming mesh might well support only small relative 
motions between the bodies before the mesh becomes invalid (negative cell 
volumes). For a single rigid mesh, all bodies within the mesh would need to 
have the same motion. 

&body_def initions 


n_moving_bodies 

= 

0 

body_frame_f orces 

= 

.false . 

output _transform 

= 

.false . 

dimensional_output 

= 

.false . 

ref .velocity 

= 

1117.0 

ref .density 

= 

0.002378 

ref .length 

= 

1.0 

body .name ( : ) 

= 

1 1 

parent.name ( : ) 

= 

1 1 

n.def ining.bndry ( : ) 

= 

0 

def ining.bndry ( : , : ) 

= 

0 

motion.driver ( : ) 

= 

' none ' 

mesh.movement ( : ) 

= 

' static ' 

x.mc ( : ) 

= 

xmc 

y.mc ( : ) 

= 

ymc 

z.mc ( : ) 

= 

zmc 

s.ref ( : ) 

= 

sref 

c.ref ( : ) 

= 

cref 

b.ref ( : ) 

= 

bref 

move.mcC : ) 

= 

1 

trim. control ( : ) 

= 

' none ' 

baseline.psi ( : ) 

= 

0.0 

steps.per.periodC : ) 

= 

0 


/ 

njnoving.bodies = 0 


This is the number of bodies in motion. 
body_frame_f orces = .false. 

This outputs aero forces acting on the body in the frame of the body 
when .true., rather than in the inertial reference frame. 

output .transform = .false. 

This outputs the transform matrix to Transf ormMatrixBody_N.hst for 
body N when .true.. 
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dimensional.output = .false. 


This outputs the body state data (displacements, velocities, and aero 
forces) in dimensional form for forced or 6-DOF motions. Use with 
ref ^velocity, ref_density, and ref_length to produce body state 
output with the desired units. 

ref_velocity = 1117.0 

This is the reference velocity to make aerodynamic forces dimensional, 
when dimensional_output = .true. Note that this should correspond 
to the sound speed if compressible. The default corresponds to standard 
sea level speed of sound, in ft/sec. 

ref_density = 0.002378 

This is the reference density to make aerodynamic forces dimensional, 
when dimensional.output = .true. The default corresponds to stan- 
dard sea level density, in slugs/ft^. 

ref_length = 1.0 

This is the reference length to make aerodynamic forces dimensional, 
when dimensional_output = .true. The default corresponds to one 
unit consistent with the values of ref.velocity and ref.density (i.e., 
1 ft for the default reference conditions). 

body_name ( : ) = ’ ’ 

This is the name used to identify the body; the array index corresponds 
to body number. 

parent_name( : ) = ’’ 

This is the name of the parent body; the array index corresponds to body 
number. The motion of a body follows (i.e., is added to) the motion of 
the parent. When naming the parent, ’ ’ signihes that the parent is the 
inertial frame. For single or independently-moving bodies, the default 
parent _name should be used. 

n_def ining_bndry ( : ) =0 

This is the number of boundaries that define the body; the array index 
corresponds to body number. 

def ining.bndry ( : , : ) = 0 

This is a list of n_def ining_bndry boundaries that define the body; the 
array index 1 corresponds to the boundary (from 1 to n_def ining_bndry) 
defining the body; the array index 2 corresponds to the body number. 
If boundary lumping is used (section B.4.2), the boundaries must corre- 
spond to lumped boundaries. 
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motion.driver ( : ) = ’none' 

This is the body motion mechanism; the array index corresponds to body 
number: 

' none ’ is for no motion. 

'forced’ uses forced motion prescribed in &f orcedunotion. 

' surf ace_f ile ’ uses surface motion prescribed in fesurf ace_motion_f rom_f ile. 

'motion_f ile’ uses motion prescribed in &motion_from_f ile. 

' 6dof ’ computes motion via 6-DOF library, which is governed by fesixdof jnotion. 

' aeroelastic ’ computes motion via &aeroelasticjnodal_data, or by 
coupling with an external FEM. 

'custom’ uses custom_kinematics; the user supplies a custom trans- 
form matrix as a function of time and design variables. 

meshunovement ( : ) = ’static’ 

This is the type of grid movement associated with body motion; the 
array index corresponds to body number: 

'static’ no mesh movement. 

' rigid’ rigid mesh movement; all nodes of the mesh rotate/translate in 
unison with the body. 

'deform’ deforms the mesh locally to accommodate the motion of the 
solid body. 

' rigid+def orm’ mesh undergoes both rigid and deforming motions 
xunc ( : ) = xmc 

The is the x-coordinate of moment center at t = 0; the array index 
corresponds to body number. 

y jnc ( : ) = ymc 

This is the y-coordinate of moment center at t = 0; the array index 
corresponds to body number. 

zunc ( : ) = zmc 

This is the z-coordinate of moment center at t = 0; the array index 
corresponds to body number. 

s_ref(:) = sref 

This is the nondimensional reference area for force and moment normal- 
ization; the array index corresponds to body number. 
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c_ref(:) = cref 

This is the nondimensional reference chord length for force and moment 
normalization; the array index corresponds to body number. 

b_ref ( : ) = bref 

This is the nondimensional reference span length for force and moment 
normalization; the array index corresponds to body number. 

move_mc(:) = 1 

This controls the movement of the moment center; the array index cor- 
responds to body number. 

' 0 ' leave moment center fixed in space 

' 1 : ’ move moment center following the body number indicated by the 
value of moveanc (body) (applicable only for rigid-body motion of body 
movejnc(body)) 

trim_control ( : ) = 'none' 

This controls whether trim as applied to the body; the array index cor- 
responds to body number. 

' none ' no trim control applied; 

'design' trim control applied via design variables; 

' body anot ion' trim control applied via moving body components; 

baseline.psi ( : ) = 0.0 

This is the starting azimuth for trim when trim is used as a design 
variable; the array index corresponds to body number. 

steps_per_period( : ) = 0 

This is the number of steps to dehne a trim period when trim is used as 
a design variable; the array index corresponds to body number. 
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B.5.2 &;forced motion 


&f orced_motioii 


rotate ( : ) 

= 

0 

rotation_rate ( : ) 

= 

0.0 

rotation_f req( : ) 

= 

0.0 

rotation_phase ( : ) 

= 

0.0 

rotation_tphase ( : ) 

= 

0.0 

rotation_ainplitude ( : ) 

= 

0.0 

rotation_origin_x( : ) 

= 

0.0 

rotation_origin_y ( : ) 

= 

0.0 

rotation_origin_z ( : ) 

= 

0.0 

rotation_vector_x( : ) 

= 

0.0 

rotation_vector_y ( : ) 

= 

1.0 

rotation_vector_z ( : ) 

= 

0.0 

rotation_start ( : ) 

= 

0.0 

rotation_duration( : ) 

= 

1.0e99 

translate ( : ) 

= 

0 

translation_rate ( : ) 

= 

0.0 

translation_freq( : ) 

= 

0.0 

translation_phase ( : ) 

= 

0.0 

translation_tphase ( : ) 

= 

0.0 

translation_amplitude ( : ) 

= 

0.0 

translation_vector_x( : ) 

= 

0.0 

translation_vector_y ( : ) 

= 

0.0 

translation_vector_z ( : ) 

= 

1.0 

translation_start ( : ) 

= 

0.0 

translation_duration( : ) 

= 

1.0e99 


rotate(:) = 0 

This is the type of rotational motion; the array index corresponds to 
body number: 

' : - 1 ’ rotate to match Cl target 
' 0 ' for no rotation. 

' 1’ for constant rotation rate, rotation_rate. 

' 2Ms sinusoidal rotation where 6 = rotation.amplitude sin(27T rotation_freq t + 

rotation.phase tt/ 180) + rotation_tphase tt/ 180 and t is nondimen- 

sionah 

' 3 ' is a square- wave doublet in rotation 6 = rotation.amplitude for the 
hrst half of the specihed rotation.duration and 6 = -rotation.amplitude 
for the second half of the specihed rotation.duration 
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rotation_rate( : ) = 0.0 


This is the nondimensional rotation rate associated with rotate=l; the 
array index corresponds to body number. For eqn_type = 'compressible’, 
the nondimensional rate is a; = uj*— — — , where u* is the dimen- 

^ ref^ref 

sional rotation rate, in rad/sec. For eqn_type = ’incompressible’, 
the nondimensional rate is a; = — ; see also section 2. 

^ ref -^ref 

rotation.! req( : ) = 0.0 

This is the nondimensional rotation reduced frequency associated with 
rotate=2; the array index corresponds to body number. For eqn.type 

L* 

= ’compressible’, the nondimensional frequency is / = f *— — — , 
where f* is the dimensional frequency, in Hertz (cycles/sec). For eqn.type 

L* 

= ’ incompressible’ , the nondimensional frequency is / = f*T 7 z — — ; 

* ref-^ref 

see also section 2. 
rotation.phase ( : ) = 0.0 

This is the rotation phase shift (in degrees) associated with rotate=2; 
the array index corresponds to body number. 

rotation.tphase ( : ) = 0.0 

This is the rotation offset (in degrees) associated with rotate=2 or 3; 
the array index corresponds to body number. 

rotation_amplitude( : ) = 0.0 

This is the rotation amplitude (in degrees) associated with rotate=2 or 
3; the array index corresponds to body number. 

rotation_origin_x( : ) = 0.0 

This is the x-coordinate of rotation center; the array index corresponds 
to body number. 

rotation_origin_y ( : ) = 0.0 

This is the ^/-coordinate of rotation center; the array index corresponds 
to body number. 

rotation_origin_z( : ) = 0.0 

This is the z-coordinate of rotation center; the array index corresponds 
to body number. 

rotation_vector_x( : ) = 0.0 

This is the x-component of a unit vector along the rotation axis; the 
array index corresponds to body number. 
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rotation_vector_y ( : ) = 1.0 


This is the ?/-component of a unit vector along the rotation axis; the 
array index corresponds to body number. 

rotation_vector_z( : ) = 0.0 

This is the ;^-component of a unit vector along the rotation axis; the 
array index corresponds to body number. 

rotation_start ( : ) = 0.0 

This is the nondimensional time at which the rotational motion begins 
the array index corresponds to body number. 

rotation_duration( : ) = l.Qe99 

This is the nondimensional time over which the rotational motion is 
active; the array index corresponds to body number. After this time the 
rotational motion is zeroed out. 

translateC:) = 0 

This is the type of translational motion; the array index corresponds to 
body number: 

' 0 ' for no translation. 

' for a constant translation rate, translation_rate. 

' 2 Ms sinusoidal translation where displacement = translation.amplitude 

sin(27T translation_freq t + translation.phase tt/ 180) + translation.tphase tt/180 

and t is nondimensional. 

translation_rate( : ) = 0.0 

This is the nondimensional translation rate associated with translate= 

1; the array index corresponds to body number. For eqn.type = ’ compressible ' , 
the nondimensional translation rate is Id = V* /a*refi where V* is the 
dimensional translation rate (for example, in ft /sec). For eqn.type = 

’ incompressible ’ , the nondimensional translation rate is Id = V* /V*refi 
see also section 2. 


translationM req( : ) = 0.0 


L\ 


This is the nondimensional translation reduced frequency associated 
with translate=2; the array index corresponds to body number. For 
eqn.type = ’ compressible ' , the nondimensional frequency is / = /* 
where f* is the dimensional frequency, in Hertz (cycles/sec). For eqn_type 
= ’ incompressible’ , the nondimensional frequency is / = f *^ — — ; 

^ ref-^ref 

see also section 2. 


lL 


ref-^ref 
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translation.phase ( : ) = 0.0 

This is the translation phase shift (in degrees) associated with translate= 
2; the array index corresponds to body nnmber. 

translation_tphase( : ) = 0.0 

This is the translation offset (in grid nnits) associated with translate=2; 
the array index corresponds to body nnmber. 

translation_amplitude( : ) = 0.0 

This is the translation amplitnde (in grid nnits) associated with translate 
2; the array index corresponds to body nnmber. 

translation_vector_x( : ) = 0.0 

This is the x-component of a nnit vector along the translation axis; the 
array index corresponds to body nnmber. 

translation_vector_y( : ) = 0.0 

This is the y-component of a nnit vector along the translation axis; the 
array index corresponds to body nnmber. 

translation_vector_z( : ) = 1.0 

This is the ;^-component of a nnit vector along the translation axis; the 
array index corresponds to body nnmber. 

translation_start ( : ) = 0.0 

This is the nondimensional start time of the translational motion; the 
array index corresponds to body nnmber. 

translation_duration( : ) = l.Qe99 

This is the nondimensional dnration of the translational motion; the 
array index corresponds to body nnmber. 
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B.5.3 ^observer motion 


This namelist specifies motion of an observer as a function of time for boundary 
animation purposes (see the &boundary_output_variables namelist for more 
details); the animation is output from the point of view of the observer. 


&observer_motion 

ob_parent_name = ' ' 

ob_rotate = 0 

ob_rotation_rate = 0.0 

ob_rotation_freq = 0.0 

ob_rotation_phase = 0.0 

ob_rotation_tphase = 0.0 

ob_rotation_amplitude = 0.0 
ob_rotation_origin_x = 0.0 
ob_rotation_origin_y = 0.0 
ob_rotation_origin_z = 0.0 
ob_rotation_vector_x = 0.0 
ob_rotation_vector_y = 1.0 
ob_rotation_vector_z = 0.0 
ob_translate = 0 

ob_translation_rate = 0.0 

ob_translation_f req = 0.0 

ob_translation_phase = 0.0 
ob_translation_tphase = 0.0 
ob_translation_amplitude = 0.0 
ob_translation_vector_x = 0.0 
ob_translation_vector_y = 0.0 
ob_translation_vector_z = 1.0 

/ 


ob_parent_ncLme = ' ' 

This is the observer parent reference frame. The default indicates the 
inertial reference frame - the same as when observer motion is not ex- 
plicitly specified. 

ob_rotate = 0 

This is the type of rotational motion: 

' 0 ' for no rotation. 

' for a constant rotation rate, ob_rotation_rate. 

' 2Ms sinusoidal rotation where 6 = ob_rotation_amplitude sin(27T ob_rotation_f req t -\- 
ob_rotation_phase tt/ 180) and t is nondimensional. 
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ob_rotation_rate = 0.0 


This is the nondimensional rotation rate associated with rotate=l. For 

L ref 


ef^ref ' 


eqn_type = ’ compressible ’ , the nondimensional rate is a; = a;* 
where uj* is the dimensional rotation rate, in rad/sec. For eqn.type = 
’ incompressible' , the nondimensional rate is a; = — ; see also 

section 2. 

ob_rotation_f req = 0.0 


This is the nondimensional rotation reduced frequency associated with 
rotate=2. 

ob_rotation_phase = 0.0 

This is the rotation phase shift (in degrees) associated with rotate=2. 


ob_rotation_tphase = 0.0 

This is the rotation phase shift (in degrees) applied to transform matrix. 


ob_rotation_amplitude = 0.0 

This is the rotation amplitude (in degrees) associated with rotate=2. 


ob_rotation_origin_x = 0.0 

This is the x-coordinate of rotation center. 
ob_rotation_origin_y = 0.0 

This is the ?/-coordinate of rotation center. 
ob_rotation_origin_z = 0.0 

This is the z-coordinate of rotation center. 
ob_rotation_vector_x = 0.0 


This is the x-component of a unit vector along the rotation axis. 
ob_rotation_vector_y = 1.0 

This is the y-component of a unit vector along the rotation axis. 
ob_rotation_vector_z = 0.0 

This is the z-component of a unit vector along the rotation axis. 
ob_translate = 0 

This is the type of translational motion: 

' 0 ' for no translation 

' 1' for constant translation rate, ob_translate_rate. 

' 2' is sinusoidal translation where displacement = ob_translation_amplitude 
sin(27T ob_translation_freq t + ob_translation_phase pi/180) and f 
is nondimensional. 
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ob_translation_rate = 0.0 


This is the nondimensional translation rate associated with translate= 

1. For eqn_type = ’compressible', the nondimensional translation 
rate is 1/ = V*/a*ref, where V* is the dimensional translation rate (for 
example, in ft/sec). For eqn.type = ’ incompressible ’, the nondimen- 
sional translation rate is Id = V* /V*ref] see also section 2. 

ob_translation_freq = 0.0 

This is the nondimensional translation rednced freqnency associated with 
translate=2. For eqn_type = ’compressible’, the nondimensional 
freqnency is / = f* — , where f* is the dimensional freqnency, in 

^ ref^ref 

Hertz (cycles/sec). For eqn_type = ’ incompressible ’, the nondimen- 
sional freqnency is / = f *^ — — ; see also section 2. 

* ref-^ref 

ob_translation_phase = 0.0 

This is the translation phase shift (in degrees) associated with translate= 

2 . 

ob_translation_tphase = 0.0 

This is the translation phase shift (in degrees) applied to transform ma- 
trix. 

ob_translation_amplitude = 0.0 

This is the translation amplitnde (in grid nnits) associated with translate 
2 . 

ob_translation_vector_x = 0.0 

This is the x-component of a nnit vector along the translation axis. 
ob_translation_vector_y = 0.0 

This is the y-component of a nnit vector along the translation axis. 
ob_translation_vector_z = 1.0 

This is the ^-component of a nnit vector along the translation axis. 
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B.5.4 Emotion from file 

This namelist specifies rigid body (and grid) motion via a file containing a 4x4 
transform matrix as a function of time. It allows user-defined motion that is 
more general than the motions available in the &f orcednnotion namelist. 


&motion_froni_f ile 

n_time_slices_f ile ( : ) 
repeat_time_f ile( : ) 
motion_f ile ( : ) 
motion_f ile_type( : ) 

/ 


= 0 

= l.Oe+99 

_ I I 

= ' transf orm_matr ix ' 


n_time_slices_f ile( : ) = 0 

This is the number of transforms (at selected points in time) dehning 
the motion of the body; the array index corresponds to body number. 
All the transforms for a particular body are contained in a single hie. 


repeat_time_f ile( : ) = l.Oe+99 

This is the nondimensional time when the motion will repeat; the array 
index corresponds to body number. 


motion_f ile( : ) = ’’ 

This is the name of the ASCII hie that contains the transform matrices 
used to set the grid position and orientation of the body for each of the 
specihed instants in time; the array index corresponds to body number. 
The following pseudo code illustrates how such a motion hie might be 
created: 

loop over time steps 
write 0 simul at longtime 
writeO xcg, ycg, zcg 
do i=l,4 

write() transf orm_matrix(i , j ) , j=l,4) 
end do 

end time step loop 

where simulation.time is the nondimensional time, and where xcg, ycg, zcg 
are the coordinates of the center of gravity of the body in grid units. 


motion_f ile_type( : ) = ’ transf orm_matrix' 

This is the type of transform matrix specihed; the array index corre- 
sponds to body number: 

' transf ormnnatrix’ specihes the transform from inertial coordinates 
to body (moving) coordinates as a matrix. 
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' inverse_transf orm' specifies the transform from body (moving) co- 
ordinates to inertial coordinates as a matrix. 
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B.5.5 ^surface motion from file 

This namelist allows the motion of surface grids to be dehned in files. Since 
only the surface is specified, mesh_movement = 'deform’ must be used to 
deform the volume mesh to conform to the specihed surface. These hies must 
be named [project_rootnamel_bodyN_timestepM.dat, where N is the body 
number and M is the time slice index (1 to n_time_slices). The hies are ASCII 
Tecplot hies with a zone title line that contains “TIME simulation_time”, 
where simulation.time is nondimensional time. The variables in the hie are 
the values of x, y, z, as well as id, where id is the global grid number of the 
surface point. 

fesurf ace_motion_f rom_f lie 
n_time_slices ( : ) = 0 
repeat_time ( : ) = l.Oe+99 

/ 

n_time_slices ( : ) = 0 

This is the number of equally spaced instants in time (and hies describing 
the shape at those times) dehning the motion of the body; the array index 
corresponds to body number. Each hie contains the surface shape at a 
point in time. 

repeat_time( : ) = l.Oe+99 

This is the nondimensional time when the motion will repeat; the array 
index corresponds to body number. 
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B.5.6 &;sixdof motion 


This namelist provides details of 6-DOF motion simulations. It requires link- 
ing to the 6-DOF library, see section A. 7.5. NOTE: most data in this namelist 
is input as dimensional data. For 6-DOF motion, the variables ref .velocity, 
ref.density and ref.length in the namelist febody .definitions must also 
be set, in units consistent with those used in fesixdof nnotion. Note (impor- 
tant): data are assumed to be in FUN3D body coordinates, which are the 
FUN3D coordinates at t=0. Note that the assumption of FUN3D coordinates 
applies to the moments of inertia. 


fesixdof _motioii 
mass ( : ) 
cg_x( : ) 
cg_y(0 
cg_z( : ) 
i_xx( : ) 

i-yy(0 

i_zz( : ) 
i_xy(:) 
i_xz( : ) 
i_yz(:) 

body_lin_vel ( : , : ) 
body_ang_vel ( : , : ) 
euler_ang( : , : ) 
gravity_dir (1 : 3) 
gravity_mag 
n_extf orce ( : ) 
n_extmoment ( : ) 
f ile_extf orce ( : , : ) 
f ile_extmoment ( : , : ) 
ignore_x_aerof orce ( : ) 
ignore_y_aerof orce ( : ) 
ignore_z_aerof orce ( : ) 
ignore_x_aeromoment ( : ) 
ignore_y_aeromoment ( : ) 
ignore_z_aeromoment ( : ) 
print_sixdof _summary 
use_specif ied_aero_data 
use_restart_mass_properties 


1.0 

0.0 

0.0 

0.0 

1.0 

1.0 

1.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0.0 

0 . 0 , 0 . 0 , - 1.0 

32.2 

0 

0 
I I 

I I 

.false . 

.false . 

.false . 

.false . 

.false . 

.false . 

.false . 

.false . 

.false . 


mass(:) = 1.0 

This is the mass of the body; the array index corresponds to the body 
number. 
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cg_x( : ) = 0.0 

This is the x-coordinate of the center of gravity; the array index corre- 
sponds to the body number. 

cg_y(:) = 0.0 

This is the y-coordinate of the center of gravity; the array index corre- 
sponds to the body number. 

cg_z( : ) = 0.0 

This is the ;^-coordinate of the center of gravity; the array index corre- 
sponds to the body number. 

i_xx(:) = 1.0 

This is the moment of inertia about the x axis as the body rotates about 
the X axis; the array index corresponds to the body number. 

i-yy(:) = 1-0 

This is the moment of inertia about the y axis as the body rotates about 
the y axis; the array index corresponds to the body number. 

i_zz(:) = 1.0 

This is the moment of inertia about the axis as the body rotates about 
the axis; the array index corresponds to the body number. 

i_xy(:) = 0.0 

This is the moment of inertia about the x axis as the body rotates about 
the y axis; the array index corresponds to the body number. 

i_xz( : ) = 0.0 

This is the moment of inertia about the x axis as the body rotates about 
the axis; the array index corresponds to the body number. 

i_yz( : ) = 0.0 

This is the moment of inertia about the y axis as the body rotates about 
the axis; the array index corresponds to the body number. 

body_lin_vel( : , : ) = 0.0 

These are the components of linear velocity; The hrst array index (rang- 
ing from 1 to 3) corresponds to the x, y, and components; The second 
array index corresponds to the body number. 

body_ang_vel( : , : ) = 0.0 

These are the components of angular velocity (degrees/sec); The hrst 
array index (ranging from 1 to 3) corresponds to the x, y, and compo- 
nents; The second array index corresponds to the body number. 
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euler_ang( : , : ) = 0.0 

These are the Euler angles (degrees); The first array (ranging from 1 to 
3) corresponds to the rotation angle components; the second array index 
corresponds to the body number. 

gravity_dir (1 : 3) = 0.0, 0.0, -1.0 

This is a unit length gravity vector. 

gravityjnag = 32.2 

This is the magnitude of the gravity vector (default units: ft/sec^). 
n_extforce( : ) = 0 

This is the number of imposed external forces, excluding gravity. The 
array index corresponds to the body number. 

n_extmoment ( : ) =0 

This is the number of imposed external moments; the array index corre- 
sponds to the body number. 

f ile_extforce( : , : ) = ’’ 

This hie specihes the external forces; the hrst array (ranging from 1 
to n_extforce) corresponds to the external force number. The second 
array index corresponds to the body number. 

f ile_extmoment ( : , : ) = ’’ 

This hie specihes the external moments; the hrst array (ranging from 1 
to n_extforce) corresponds to the external force number. The second 
array index corresponds to the body number. 

ignore_x_aeroforce( : ) = .false. 

Flag to ignore the inhuence of the x-component of the aerodynamic force 
on the 6-DOF motion of the body; the array index corresponds to the 
body number. 

ignore_y_aeroforce( : ) = .false. 

Flag to ignore the inhuence of the y-component of the aerodynamic force 
on the 6-DOF motion of the body; the array index corresponds to the 
body number. 

ignore_z_aeroforce( : ) = .false. 

Flag to ignore the inhuence of the z-component of the aerodynamic force 
on the 6-DOF motion of the body; the array index corresponds to the 
body number. 
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ignore_x_aeromoment ( : ) = .false. 

Flag to ignore the influence of the x-component of the aerodynamic 
moment on the 6-DOF motion of the body; the array index corresponds 
to the body number. 

ignore_y_aeromoment ( : ) = .false. 

Flag to ignore the influence of the y-component of the aerodynamic mo- 
ment on the 6-DOF motion of the body; the array index corresponds to 
the body number. 

ignore_z_aeromoment ( : ) = .false. 

Flag to ignore the influence of the ;^-component of the aerodynamic mo- 
ment on the 6-DOF motion of the body; the array index corresponds to 
the body number. 

print_sixdof .summary = .false. 

Print out a summary of the 6-DOF data for each body at each time step, 
from within the 6-DOF solver itself; useful for verifying that the 6-DOF 
library is getting the correct data from FUN3D 

use.specif ied_aero_data = .false. 

Use aero forces and moments read from flle(s) instead of the computed 
values (used for validating 6-DOF library implementation). When this 
option is used, files must be specified for ALL bodies moving under 6- 
DOF. For body N, the file name must be named specified_aero_data_bodyN.dat 

use_restart Jiass.properties = .false. 

Use mass and moments of inertia from the FUN3D restart file instead of 
those in this namelist; only needed FUN3D has modified the mass and 
inertia during the simulation. 
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B.5.7 &;aeroelastic modal data 

This namelist specifies modal data for static and dynamic aeroelastic analysis 
via time integration of the structural dynamics equations (see for example [62]). 

&aeroelastic_modal_data 
plot_modes = .false. 

nmode(:) = 0 

grefl(:) = 1.0 

uinf ( : ) =0.0 

qinf ( : ) =0.0 

gdispOC: , :) =0.0 

gvel0( : , : ) =0.0 

gf orceOC : , : ) =0.0 

gmass ( : , : ) =0.0 

f req( : , : ) =0.0 

damp ( : , : ) =0.0 

moddf 1 ( : , : ) =0 

moddfl_amp( : , : ) = 0.0 

moddf l_freq( ) = 0.0 
moddf l_t0(: , :) =0.0 

moddf l_add( ) = 0 

mode_f ile_f ormat = 'ascii' 

/ 

plot_modes = .false. 

This generates tecplot files of each mode shape added to the body surface. 
These can be inspected these to insure the validity of input modal surface 
data. 

nmode ( : ) =0 

This is the number of aeroelastic modes used to represent the structural 
deformation; the array index indicates the body number. 

grefl(:) = 1.0 

This is the scaling factor between CFD grid units and the structural 
dynamics equation units; the array index indicates the body number. 

uinf(:) = 0.0 

This is the freestream velocity, in structural dynamics equation units; 
the array index indicates the body number. 

qinf ( : ) = 0.0 

This is the freestream dynamic pressure, in structural dynamics equation 
units; the array index indicates the body number. 
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gdispOC : , : ) =0.0 

This is the generalized displacement of a specihed mode at the starting 
time step. It is used to perturb a mode to excite a dynamic response. 
The first array index indicates the mode number and the second array 
index indicates the body number. 

gvelOC : , : ) = 0.0 

This is the generalized velocity of a specihed mode at the starting time 
step. It is used to perturb a mode to excite a dynamic response. The 
hrst array index indicates the mode number and the second array index 
indicates the body number. 

gforceOC : , : ) = 0.0 

This is the generalized force of a specihed mode at the starting time 
step. It is used to perturb a mode to excite a dynamic response. The 
hrst array index indicates the mode number and the second array index 
indicates the body number. 

gmassC : , : ) = 0.0 

This is the generalized mass of a specihed mode. The hrst array index 
indicates the mode number and the second array index indicates the 
body number. 

freqC : , : ) = 0.0 

This is the frequency of specihed mode, in rad/sec. The hrst array index 
indicates the mode number and the second array index indicates the 
body number. 

dampC : , : ) = 0.0 

This is the damping ratio of specihed mode. The hrst array index indi- 
cates the mode number and the second array index indicates the body 
number. 

moddf 1 ( : , : ) = 0 

This is the type of time-varying mode perturbation. The hrst array 
index indicates the mode number and the second array index indicates 
the body number. 

' - 1 ’ is the modal displacement and velocity held hxed at the initial 
values specihed by gdispO and gvelO, respectively. 

' 0 ' is no modal perturbation. 

‘ 1 ’ is a harmonic modal oscillation. 

' 2 ' is a Gaussian pulse modal dehection. 
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'3' is a step pulse modal deflection. 

'5' specifles simultaneous inputs for reduced order model, 
moddf l_amp( : , : ) = 0.0 

This is the amplitude of mode perturbation. The first array index indi- 
cates the mode number and the second array index indicates the body 
number. 

moddf l_f req( : , : ) = 0.0 

This is the frequency of mode perturbation. If moddf 1=2, it is the Gaus- 
sian pulse half-life. The first array index indicates the mode number and 
the second array index indicates the body number. 

moddf l_t0( ) = 0.0 

If moddf 1=1, this is the dimensional time at which the sinusoidal pertur- 
bation starts. If moddf 1=2, this is the dimensional time of the center of 
the Gaussian pulse. If moddf 1=3, this is the start time of a step pulse. 
The first array index indicates the mode number and the second array 
index indicates the body number. 

moddf l_add( ) = 0 

This determines how the modal perturbation is applied. The first array 
index indicates the mode number and the second array index indicates 
the body number. 

' 0 ' replaces the perturbation with the static aeroelastic solution. 

' 1 ' adds the perturbation to an existing static aeroelastic solution (if 
one exists). 

mode_f ile_f ormat = ’ascii’ 

This indicates the type and format of the mode-shape files that are read 
by the code. mode_file_f ormat = ’ascii’ indicates the files are ASGII 
Tecplot files, with a file extension .dat; mode_file_f ormat = ’ stream’ 
indicates binary (stream) DDF files, with a file extension .ddfb. 
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B.5.8 ^composite overset mesh 


This namelist provides the input for SUGGAR++ (see the documentation 
supplied with SUGGAR++ for details). 

&composite_overset_mesh 
input_xml_f ile = ' ' 

/ 


input _xml_f ile = ' ' 

This is the hie containing the XML commands for SUGGAR++. Specify 
the same Input. xml hie that was used to generate the initial composite 
grid with the “stand-alone” SUGGAR-I--I- code. 
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B.5.9 &body motion trim 

This namelist provides the input for trimming a moving body to match se- 
lected trim targets. Trim is achieved by moving one or more bodies via rota- 
tion, translation, or modal amplitude. This option often relies on parent-child 
composite bodies. For example, a wing composite body (the parent) may be 
comprised of a main element (a child) and a flap element (another child). If 
the wing composite body is to be trimmed to match both a lift target and a 
pitching moment target, the lift target can be achieved by adjusting the rota- 
tion angle of the wing composite body, and the moment target can be achieved 
by adjusting the rotation angle of the flap element. An imposed restriction is 
that each trim target is achieved by moving a single body; that single body 
could however be a composite parent-child body 

&body_motion_trim 
trim_ref _f rame 
n_trim_targets ( : ) 
trim_variable ( : , : ) 
trim_value ( : , : ) 
body_used_f or_trim( : , : ) 
motion_used_f or_trim( : , : ) 
mode_used_f or_trim( : , : ) 
per_step_limit ( : , : ) 
update_f requency ( : , : ) 
trim_jacobian( 

/ 

trim_ref .frame = 'body’ 

This sets the reference frame in which trim targets are to be satished. 
Note that wind-aligned trim targets (Cl and Cd) are unaffected by the 
choice of trim_ref .frame. 

n.trim.targets ( : ) = 0 

This sets the number of trim targets for the body; the array index cor- 
responds to body number of the body to be trimmed. 

' 0 :max_trim_targets ’ up to three simultaneous trim targets per body; 
trim_variable( : , : ) = ’none’ 

This specihes the force/moment variables to trim to; the array index 
1 corresponds to the trim target from 1 to n.trim.targets set for the 
body; the array index 2 corresponds to the body number of the body to 
be trimmed. 

' cl ’ trims to a specihed lift coefficient 
' cd ’ trims to a specified drag coefficient 


= 'body' 
= 0 

= ' none ' 
= 0.0 
= 0 

= ' none ' 
= 0 
= 0.0 
= 1 
= 0.0 
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' cw’ trims to a specified weight coefficient; weight is assumed to act in 
the (negative) z-direction. Trim is computed as if a thrust is applied 
along the body x-axis to counterbalance drag; if the body x-axis is not 
aligned with the inertial x-axis, this thrust will also have a contribution 
in the inertial z-direction. 

' cx ’ trims to a specified force coefficient in the x-direction 
' cy ’ trims to a specihed force coefficient in the y-direction 
' cz ’ trims to a specified force coefficient in the z-direction 
' cmx ’ trims to a specihed moment coefficient about the x-axis 

' cmy ’ trims to a specihed moment coefficient about the y-axis 

' cmz ’ trims to a specihed moment coefficient about the z-axis 

trimwalue ( : , : ) = 0.0 

This specihes the desired numerical values of the trim variables at the 
time condition; the array index 1 corresponds to the trim target from 1 
to n_trim_targets set for the body; the array index 2 corresponds to 
the body number of the body to be trimmed. 

body_used_f or_trim( : , : ) = 0 

This specihes the body number of the body that is moved to achieve the 
trim target; the array index 1 corresponds to the trim target from 1 to 
n_trim_targets set for the body; the array index 2 corresponds to the 
body number of the body to be trimmed. 

motion_used_f or_trim( : , : ) = 'none' 

This specihes the type of body motion used to achieve the trim target; the 
array index 1 corresponds to the trim target from 1 to n_trim_targets 
set for the body; the array index 2 corresponds to the body number of 
the body to be trimmed. 

'rotate' trims by rotating the body_used_f or.trim 

'translate' trims by translating the body_used_f or_trim 

'mode' trims by adjusting modal amplitude of the body_used_f or.trim 

mode_used_f or_trim( : , : ) = 0 

This specihes the aeroelastic mode number used to achieve the trim 
target; only used for modal aeroelastic simulations, and only active when 
motion_used_for_trim='mode' ; the array index 1 corresponds to the 
trim target from 1 to n_trim_targets set for the body; the array index 
2 corresponds to the body number of the body to be trimmed. 
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per_step_limit ( : , : ) = 0.0 

This specifies the maximum amount that the motion_used_f or_trim can 
change during each attempt to achieve trim; if the motion is rotation, 
the units are degrees; if translation, the units are grid units; if modal 
amplitude, the units are (I have no idea); the array index 1 corresponds 
to the trim target from 1 to n_trim_targets set for the body; the array 
index 2 corresponds to the body number of the body to be trimmed. 

update_f requencyC : , : ) = 1 

This specifies the frequency with which the trim variable is updated 
trim_jacobian( : , : , : ) = 0.0 

This specifies the sensitivities of the specified trim_variable(s) to a 
change in the specified motion_used_f or_trim(s). Thus it is an n_trim_targets 
X n_trim_targets array for each body with trim_control = ' body .motion ’ . 
The array index 1 corresponds to the trim variable, array index 2 cor- 
responds to the control motion, the array index 3 corresponds to the 
body number of the body to be trimmed. The sign of the entries is 
important. For example, if the trim variable is lift, and the motion is 
rotation, then if an increase in the rotation angle produces an increase 
in lift, then the sign of that entry in trim.jacobian should be positive. 
Conversely, if an increase in rotation angle produces a decrease in lift, 
then the sign of that entry in trim.jacobian should be negative. If the 
motion_used_f or.trim is rotation, the sensitivity is assumed to be input 
per degree. 


285 



B.6 rotor, input 


Fun3D is capable of modeling a rotating blade system using different levels of 
approximation. In order of increasing complexity /fidelity /cost, rotor systems 
may be analyzed using either a time-averaged actuator disk, or via first prin- 
ciples modeling of the moving, articulated, rotor blades using overset, moving 
grids. The actuator method utilizes moment um/energy source terms to rep- 
resent the influence of the rotating blade system. Use of the source terms 
simplihes grid generation, since the actuator surfaces do not need to be built 
into the computational grid. However, the computational grid should have 
some rehnement in the vicinity of the actuator surfaces to obtain accurate 
results. The steady-state actuator disk capability was originally implemented 
by Dave O’Brien, at the time a PhD candidate at Georgia Tech. [63] O’Brien 
also initiated the overset capability in Fun3D, which was later extended and 
coupled to a rotorcraft comprehensive code by Biedron et al. [64] 

The rotor. input hie is used primarily for specifying input quantities related 
to an actuator surface model for rotor /propeller combinations. When using 
overset, moving grids and/or coupling Fun3D to a rotorcraft comprehensive 
code for a more detailed simulation, a limited number of the input helds in 
the rotor. input hie are also required. The helds required for coupled ro- 
torcraft simulations include (required for coupled simulation) in the variable 
description. The command line option — rotor is required for both types of 
analysis. 

Fun3D can also use the actuator disk library developed by Dave O’Brien 
for the Department of Defense HI- ARMS/CREATE/HELIOS project. Soft- 
ware Module for Engineering Methods of Rotor Dynamics (SMEMRD). The 
Fun3D team is unable to provide technical support for SMEMRD; please 
contact Dave O’Brien directly for assistance (David.ObrienJr@us.army.mil). 
SMEMRD adds the ability to trim to thrust values and use airfoil lookup 
tables. The --hiarms_rotor command line option activates the SMEMRD 
model. 

The two parameters used to set the hight condition and force/moment coef- 
hcient normalization in compressible rotorcraft simulations are mach_number in 
funSd.nml and Vinf_Ratio in rotor. input. To nondimensionalize the forces 
with the rotor tip velocity, set machjiumber to the tip mach number and 
Vinf_Ratio to the ratio of freestream velocity to rotor tip velocity. When 
mach_number is the tip mach number then reynolds_number should be set to 
the corresponding tip Reynolds number. To nondimensionalize the forces with 
the freestream velocity, set machjiumber to the freestream mach number and 
Vinf_Ratio to one. The Vinf_Ratio will still affect the force nondimension- 
alization as described above, for incompressible solutions. 

A sample rotor, input hie is shown below for a conventional main rotor 
and tail rotor helicopter. 
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# Rotors 

Vinf _Ratio 

Write Soln 

Force_ref 

Moment_ref 


2 

0.1 

50 

1.0 

1.0 







Rotor Type 

Load Type 

# Radial 

# Normal 

Tip Weight 


1 

0 

50 

720 

0.0 


XO_rotor 

Y0_rotor 

Z0_rotor 

phil 

phi2 

phiS 

0.00 

0.00 

0.00 

0.00 

-5.00 

0.00 

Vt_Ratio 

ThrustCof f 

TorqueCoff 

psiO 

PitchHinge 

DirRot 

1.00 

0.005 

0.00 

0.00 

0.0 

0 

# Blades 

TipRadius 

RootRadius 

BladeChord 

FlapHinge 

LagHinge 

4 

1.00 

0.00 

0.05 

0.00 

0.00 

LiftSlope 

alpha, L=0 

cdO 

cdl 

cd2 


6.28 

0.00 

0.002 

0.00 

0.00 


CL_max 

CL_min 

CD_max 

CD_min 

Swirl 


1.50 

-1.50 

1.50 

-1.50 

0 


ThetaO 

ThetaTwist 

Thetals 

Thetalc 

Pitch-Flap 


5.00 

-2.00 

0.00 

0.00 

0.00 


# FlapHar 

BetaO 

Betals 

Betalc 



0 

0.00 

0.00 

0.00 



Beta2s 

Beta2c 

BetaSs 

BetaSc 



0.00 

0.00 

0.00 

0.00 



# LagHar 

DeltaO 

Deltals 

Deltaic 



0 

0.00 

0.00 

0.00 



Delta2s 

Delta2c 

DeltaSs 

DeltaSc 



0.00 

0.00 

0.00 

0.00 








Rotor Type 

Load Type 

# Radial 

# Normal 

Tip Weight 


1 

0 

100 

720 

0.0 


X0_rotor 

Y0_rotor 

Z0_rotor 

phil 

phi2 

phiS 

1.00 

0.00 

0.00 

90.00 

0.00 

0.00 

Vt_Ratio 

ThrustCof f 

TorqueCoff 

psiO 

PitchHinge 

DirRot 

1.25 

0.001 

0.00 

0.00 

0.0 

0 

# Blades 

TipRadius 

RootRadius 

BladeChord 

FlapHinge 

LagHinge 

3 

0.20 

0.00 

0.01 

0.00 

0.00 

LiftSlope 

alpha, L=0 

cdO 

cdl 

cd2 


6.28 

0.00 

0.002 

0.00 

0.00 


CL_max 

CL_min 

CD_max 

CD_min 

Swirl 


1.50 

-1.50 

1.50 

-1.50 

1 


ThetaO 

ThetaTwist 

Thetals 

Thetalc 

Pitch-Flap 


8.00 

0.00 

0.00 

0.00 

0.00 


# FlapHar 

BetaO 

Betals 

Betalc 



0 

0.00 

0.00 

0.00 



Beta2s 

Beta2c 

BetaSs 

BetaSc 



0.00 

0.00 

0.00 

0.00 



# LagHar 

DeltaO 

Deltals 

Deltaic 



0 

0.00 

0.00 

0.00 



Delta2s 

Delta2c 

DeltaSs 

DeltaSc 



0.00 

0.00 

0.00 

0.00 




The header line is where the user specihes the number of rotors, the 
freestream velocity ratio, and how often to output the plotSd loading hie. 
The remainder of the hie is in a block structure, where each block represents 
the inputs for one rotor. The hrst line of each block is a text line that can be 
edited to keep the rotors organized for the user. The input values do not have 
to be in a hxed format (spaces and number of decimal points do not matter), 
but the input values do have to be in the correct order as noted by the header 
lines for the individual input parameters. 
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B.6.1 Header 

# Rotors (required for eoupled simulation) 

This is the number of actuator surfaces to create. The number of rotor 
input blocks in this file must match the number of rotors specihed. 

Vinf _Ratio (required for eoupled simulation) 

This is the ratio of the freestream velocity to the the velocity used for 
force normalization. The force normalization velocity is typically the tip 
velocity for rotorcraft applications. 

Write Soln 

This is the frequency (in iterations) of PlotSD rotor loading data output, 
which is pairs of source_grid_00000.p3d and source_data_00000.p3d 
files. To write once, set Write Soln to steps. 

Force_ref 

This is the conversion factor to obtain forces in alternate units, 

1.0 will output the standard Fun 3D nondimensionalization 

'will output standard rotorcraft nondimension- 
alization 

Prefofef^ref 'wHl output dimeusioual units 
Moment_ref 

This is the conversion factor to obtain moments in alternate units. 

1.0 will output the standard Fun 3D nondimensionalization 

will output standard rotorcraft nondimension- 
alization 

Prefofef^ref 'wHl output dimeusioual units 

B.6.2 Actuator Surface Model 
Rotor Type 

Type of rotor model to apply, 

1 models the rotor as an actuator disk. 

2 models the rotor as actuator blades. 

Load Type 

Type of loading to apply to the rotor model. 
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1 is a pressure jump based on ThrustCoeff that is constant over the 

disk. 

2 is a pressure jump based on ThrustCoeff that increases linearly with 

radius. 

3 is blade element based loading based dehned by the blade element 

parameters dehned in section B.6.6 and section B.6.7. 

4 is user specihed source geometry and strength. Not recommended un- 

less you have experience in actuator disk modeling. See the subrou- 
tine read_user_source2 in LibF90/rotors.f 90 for input format. 

5 is user specihed thrust and torque radial distributions in the hie 

propeller_propertiesN.dat, where N is the rotor index. The hrst 
line of the hie is the number of radial stations. The following lines 
have three numbers per station, with r/R, ^0^, 00- 

6 is a body force based on on the optimal distribution of Goldstein 

[65] implemented as described by Stern, Kim, and Patel. [66] Use 
ThrustCoeff to set the thrust and TorqueCoeff to produce swirl 
(with Swirl=l). 

# Radial 

This is the number of sources to distribute along the blade radius. This 
should be set to approximately match the resolution of the volume grid, 
otherwise a suggested value is 100. 

# Normal 

This is the number of sources to distribute along the circumferential 
direction. This should be set to approximately match the resolution 
of the volume grid. For Rotor Type=l, 720 is suggested for a source 
every 0.5 degrees. For Rotor Type=2, 20 points in the chord direction is 
suggested. 

Tip Weight 

This is the hyperbolic weighting factor for distributing sources along the 
blade radius. A suggested value is 0.0, which yields uniform distribu- 
tion. A value larger than 2.0 is not advised, because this large a value 
concentrates too many sources at the blade tip. 

B.6.3 Rotor Reference System 

X0_rotor (required for coupled simulation) 

This is the x coordinate of the hub center of rotation, in grid units. 
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YO_rotor (required for coupled simulation) 

This is the y coordinate of the hub center of rotation, in grid units. 
Z0_rotor (required for coupled simulation) 

This is the coordinate of the hub center of rotation, in grid units, 
phil 

This is the hrst Euler angle describing a rotation about the x axis, in 
degrees. For a propeller oriented in the x-positive direction, this should 
be 0. 

phi2 

This is the second Euler angle describing a rotation about the 02 axis, in 
degrees. For a propeller oriented in the x-positive direction, this should 
be -90. 

phi3 

This is the third Euler angle describing a rotation about the 63 axis, in 
degrees. For a propeller oriented in the x-positive direction, this should 
be 0. 

The Euler angles must be input correctly to obtain the correct orientation 
of the source based actuator disk. The following example illustrates how to 
determine these angles. Figure B5 depicts the rotations phil = 10, phi2 = 
— 15, and phi3 = 15. Initially, the thrust is assumed to be in the 2; direction 
and the disk is located in the x — y plane. The hrst rotation of phil about 
the X axis takes the x — y — z system to the Oi — 02 — 03 system shown in red. 
The second rotation of phi 2 about the 02 axis takes the ui — 02 — 03 system 
to the 61 — 62 — bs system shown in green. The hnal rotation of phi3 about 
the &3 axis takes the 61 — 62 ~ ^3 system to the rotor reference system shown in 
blue. The black circle represents the initial disk orientation and the blue circle 
represents the hnal disk orientation. In general phil and phi2 are sufficient 
to dehne the thrust orientation. The variable phi3 only changes the location 
of the zero azimuth angle dehnition for the rotor. 

B.6.4 Rotor Loading 

Vt_Ratio (required for coupled simulation) 

This is the ratio of the tip speed to the velocity used for force nor- 
malization, which is mach_number for compressible simulations. For 
Load Type = 3, Load Type = 5, and Load Type = 6 a negative value 
will reverse the rotation direction. The propeller convention is J = ^, 
where 14 is speed of advance (true airspeed), n is revolutions per unit 
time, and D is diameter, i.e, Vt_Ratio= j. 
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Figure B5: Rotor disk Euler angles. 


ThrustCof f 

This is the rotor thrust coefficient dehned as, Ct = Thrust / {n p^efR^ iS^DimRY) i 
when Load Type=l, Load Type=2, or Load Type=6. The blade element 
model does not trim to specihed thrust coefficient. The propeller con- 
vention is Kt = Thrust / {prefn^DYi where n is revolutions per unit 
time, and D is diameter, i.e, ThrustCoff= -^Kt- 

TorqueCof f 

This is the rotor torque coefficient defined as, Cq = Torque / {TiprefR^i^DimRY), 
when Load Type=6. The blade element model is not effected by spec- 
ified torque coefficient. The propeller convention is Kq = Torque / 
(prefn^D^), where n is revolutions per unit time, and D is diameter, i.e, 
ThrustCoff= -^Kq. 


B.6.5 Blade Parameters 

psiO (required for eoupled simulation) 

This is the initial azimuthal position of blade one, in degrees; the azimuth 
position is defined as zero when the blade is oriented along the x-axis 
with the tip at the most positive x location. 

PitchHinge (required for eoupled simulation) 

This is the radial position of the blade pitch hinge normalized by tip 
radius. 

DirRot (required for coupled simulation) 

This is the direction of rotor rotation. Zero is counter-clockwise rota- 
tion and one is clockwise rotation. This option only applies to coupled 
simulation, not actuator models. 
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# Blades (required for coupled simulation) 

This is the number of rotor blades. It is only used for Load Type=3 and 
overset rotor simulations. 

TipRadius (required for coupled simulation) 

This is the radius of the blade, in grid units. 

RootRadius (required for coupled simulation) 

This is the radius of the blade root, in grid units. It accounts for the 
cutout region immediately surrounding the hub. 

BladeChord (required for coupled simulation) 

This is the chord length of the blade, in grid units. It can only handle 
rectangular blade planforms and is only valid for Load Type=3. 

FlapHinge (required for coupled simulation) 

This is the radial position of the blade flap hinge normalized by tip 
radius. 

LagHinge (required for coupled simulation) 

This is the radial position of the blade lag hinge normalized by tip radius. 

B.6.6 Blade Element Parameters for Load Type=3 

These inputs are used to set the blade element lift and drag curves according 
to: 

Cl = LiftSlope(o; — aL=o) (Bl) 

and 

Cd = cdO + cdl a + cd2 (B2) 

LiftSlope 

This is the lift curve slope per radian, 
alpha, L=0 

This is the zero lift angle of attack, in degrees. 
cdO, cdl, and cd2 

These are the quadratic drag polar coefficients; where cdl is per radian 
and cd2 is per radian squared. 

CL_max and CL_min 

These limiters to control the lift coefficient beyond the linear region. 
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CD_max and CD-inin 


These limiters to control the drag coefficient. 

Swirl 

0 neglects the sources terms that create rotor swirl. 

1 the swirl inducing source terms. 

B.6.7 Pitch Control Parameters for Load Type=3 

These inputs are used to specify the pitch/flap controls according to: 

9 = ThetaO + ThetaTwist {r /R) + Thetalc cos('^) + Thetals sin('^) (B3) 
ThetaO 

This is the collective pitch dehned at r/i?=0, in degrees. 

ThetaTwist 

This is the total amount of linear blade twist from the origin to the blade 
tip, in degrees. 

Thetals 

This is the longitudinal cyclic pitch input, in degrees. 

Thetalc 

This is the lateral cyclic pitch input, in degrees. 

Pitch-Flap 

Pitch-Flap coupling parameter [not implemented]. 

B.6.8 Prescribed Flap Parameters 

These inputs are used to specify the flap harmonics according to: 

P = BetaO + Betals sin('^) -|- Betalc cos('^) 

+Beta2s sin(2'^) -|- Beta2c cos(2-^) (B4) 

+Beta3s sin(3'^) -p BetaSc cos(3-^) 

# FlapHar 

This is the number of flap harmonics to include. The valid input range 
is zero to three. 

BetaO 

This is the coning angle, in degrees. 
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Betals and Betalc 


This is the hrst flap harmonics, in degrees. 

Beta2s and Beta2c 

This is the second flap harmonics, in degrees. 

BetaSs and BetaSc 

This is the third flap harmonics, in degrees. 

B.6.9 Prescribed Lag Parameters 

These inputs are used to specify the lag harmonics according to: 

S = DeltaO + Deltals sin('^) + Deltaic cos('^) 

+Delta2s sin(2-^) + Delta2c cos(2-^) (B5) 

+Delta3s sin(3'^) + DeltaSc cos(3'^) 


# LagHar 

This is the number of lag harmonics to include. The valid input range 
is zero to three. 

DeltaO 

This is the coning angle, in degrees. 

Deltals and Deltaic 

This is the first lag harmonics, in degrees. 

Delta2s and Delta2c 

This is the second lag harmonics, in degrees. 

DeltaSs and DeltaSc 

This is the third lag harmonics, in degrees. 

B.7 tdata 

This file defines the gas model when eqn_type = ’generic’. A keyword is 
required on the first line of tdata. Many of these models require additional 
information as detailed in each keyword section. 

Some keywords require a list the species. For these keywords, additional 
groups of species can be specified for boundary conditions after a blank line. 
If new species are introduced in subsequent instances their mass fractions are 
automatically initialized to zero at any previous inflow boundary. All the 
species entries in this file are available as reactants throughout the entire flow 
field. 
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B.7.1 perfect gas Keyword 

A perfect gas can be modeled with the perf ect_gas keyword. The parameters 
can be explicitly defined in tdata by the namelist &species_properties. The 
namelist in tdata has different variables than the &species_properties in 
species_thermo_data. Here is an example of the namelist with defaults that 
are all given in SI units, 


perf ect_gas 
&species_properties 


gamma 

mol_wt 

sutherl 

suther2 

prand 

/ 


1.4 

28.8 

0. 1458205E-05 
110.333333 
0.72 


Where gamma is the gas specihc heat ratio, mol_wt is the gas molecular weight, 
prand is the gas Prandtl number, and sutherl and suther2 are the hrst and 
second Sutherland’s viscosity coefficients, Si and S 2 , in 




^ 3/2 

T + S2 


(B6) 


These defaults are used if the &species_properties namelist or any of its 
variables are omitted. 


B.7.2 equilibrium air t Keyword 

The equilibrium_air_t keyword engages the Tannehill curve hts for thermo- 
dynamic and transport properties of equilibrium air. [67] This keyword does 
not require additional lines. 

equilibrium_air_t 

B.7.3 equilibrium_air_r Keyword 

The equilibrium_air_r keyword engages the Tannehill curve hts for transport 
properties and a table look-up for equilibrium gases [68], This keyword does 
not require additional lines. 

equilibrium_air_r 
B.7.4 one Keyword 

This one-temperature (1-T) model assumes that all the species are thermally 
in equilibrium state; the translational temperature T and vibrational tempera- 
ture T„ are equal. This is a mixture of thermally perfect gases and multi-species 
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transport. In this example, only molecular oxygen and nitrogen are present 
on the inflow boundary, but atomic nitrogen and oxygen and nitric oxide may 
be produced elsewhere in the flow fleld due to chemical reactions. The inflow 
boundary mass fraction of molecular oxygen and nitrogen is given next to their 
symbols. Mass fractions should sum to one. 


one 

N2 .767 
N 

02 .233 

0 

NO 

B.7.5 two Keyword 

This two-temperature (2-T) model assumes that energy distribution in the 
translational and rotational modes of heavy particles (not electrons) are equili- 
brated at translational temperature T and all other energy modes (vibrational, 
electronic, electron translational) are equilibrated at vibrational temperature 
Ty. In this example, the gas is assumed to be a mixture of 11 thermally perfect 
gases. The inflow boundary mass fraction of molecular oxygen and nitrogen is 
given next to their symbols. Mass fractions should sum to one. Other products 
are the results of chemical reactions flow fleld. 


two 


N2 

.767 

N 


02 

.233 

0 


NO 


02+ 


0+ 


N0+ 


e- 



B.7.6 FEM Keyword 

This Free-Energy Minimization (FEM) model causes the species continuity 
equations to be replaced with elemental continuity equations and equilibrium 
relations for remaining species. In this example, the gas is assumed to be a 
mixture of 11 thermally perfect gases. The inflow boundary mass fraction of 
molecular oxygen and nitrogen is given next to their symbols. Mass fractions 
should sum to one. Other products are the results of chemical reactions flow 
fleld. 
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FEM 

N2 .767 
N 

02 .233 

0 

NO 

02 + 

0 + 

N0+ 

e- 

B.8 species_thermo_data 

The species_thermo_data file is the master hie for species thermodynamic 
data. The majority of simulations do not require changes to this hie. Investi- 
gating other sources of thermodynamic data is the only reason to edit this hie. 
If the hie is not found in the local run directory, it is assumed to be located in 
the [install-prefix] /share/physics_modules directory. See section A. 3 
for [install-prefix]. 

Each species record consists of the species name, a &species_properties 
namelist, the number of thermodynamic property curve ht ranges, and the 
curve ht coefficients for each range. [69] No blank line is allowed in this 
hie. This &species_properties namelist has diherent variables than the 
&species_properties in tdata. The elements of the &species_properties 
namelist are: 

mol_wt 

This sets the molecular weight of the particle. It is always required. 
molecule = .false. 

This is denotes the the species a molecule (composed of more than one 
atom) ; 

ion = .false. 

This is denotes the the species a charged particle. Do not set it for neu- 
trals and electrons. This will initializes electron-neutral energy exchange 
cross section and sum of the charges. 

charge = 0 

This is an integer number to determine number of positive charges in 
particle. It should only be used with ion = .true. 

elec_impct_ion = -l._dp 

This sets the energy for neutrals ion=. false, that is required to liberate 
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an electron when the neutral impact a free electron, in units of electron 
volts (eV). 

siga(:) = -l._dp 

This is an array of three real numbers, which correspond to the curve 
fit coefficients for electron-neutron energy exchange. The cross section 
is dehned as 

a^n = a + bT + cT"^ (B7) 

where (Ten is the electron-neutron energy exchange collision cross section 
in m^. The variables a, b, and c are the curve £t coefficients and T is 
the gas temperature. [70,71] For example, siga=7.5e-20 , 0, 0. 

disoc_ener = 0._dp 

This is the dissociation energy of molecule in electron volts (eV). 
alantel = 0._dp 

This is the Landau-Teller constant to compute vibrational relaxation 
time for molecule. [72,73]. It is required when molecule=.true.. 

cprtO = 0._dp 

This non-dimensional real number defines translational-rotational heat 
capacity. It is normalized by the gas constant and is equal to 

f + 2 

cprtQ = (B8) 

where / is the number of degrees of freedom in translation and rota- 
tion. The defaults for atoms and diatomic molecules are 2.5 and 3.5, 
respectively. 

A portion of the species_thermo_data that provides thermodynamic prop- 
erties of carbon is shown below. 


C 1 
&species_properties 2 
molecule = .false. 3 
ion = .false. 4 
charge =0 5 


elec_impct_ion = 11.264 

siga = 7.5e-20, 5.5e-24, -l.e-28 

mol_wt = 12.01070 


0.64950315E+03 -0 . 96490109E+00 0 . 25046755E+01 -0 . 12814480E-04 

0.19801337E-07 -0 . 16061440E-10 0 . 53144834E-14 0 . OOOOOOOOE+00 
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0.85457631E+05 

-0.12891365E+06 

0.17420927E-06 

0.84105978E+05 

0.44325280E+09 

0.66495953E-06 

0.23552734E+07 


0.47479243E+01 

0.17195286E+03 

-0.29028178E-10 

0.41300474E+01 

-0.28860184E+06 

-0.22300788E-10 

-0.64051232E+03 


200.000 1000 
0.26460444E+01 
0. 16421824E-14 
1000.000 6000 
0.77371083E+02 
0.28993887E-15 
6000.000 20000 


000 

-0.33530690E-03 

O.OOOOOOOOE+00 

000 

-0.97152819E-02 

O.OOOOOOOOE+00 

000 


13 

14 

15 

16 

17 

18 
19 


The species name is defined in line 1 . Between lines 2 and 9 species properties 
are defined. Line 10 shows that there are three thermodynamic property curve 
fits for temperature ranges of 200 K < T < 1,000 K, 1,000 K < T < 6,000 K, 
and 6,000 K < T < 20,000 K. Each data range consists of 12 real numbers. 
Four real numbers must be given on each line. The first 10 real numbers are the 
thermodynamic curve fit coefficients, and the last two real numbers identify 
the temperature range for the given curve fit coefficients. These coefficients 
are used to calculate the following thermodynamic properties 


Cp(T)/R — a\T ^ + CL 2 T ^ + 03 + CI 4 T + cb^T'^ + ciqT^ + (B9) 

h(T)/RT = —aiT ^ + 02 ^ ^In T-\-a^-\-a4 — -\-a^——-\-aQ— — (BIO) 

^ o ^ 0 -t 

rjn — 2 rp2 2^3 

s(T)/R = — ^ a^ln T Q 4 T (Bll) 

where T is the gas temperature, R is the universal gas constant, Cp, h, and s 
are the species specific heat, enthalpy and entropy, respectively, and ai are the 
provided curve fit coefficients in species_thermo_data. 

The following corrections will be applied if the gas temperature is out of 
the given range for the given curve fit coefficients: 


where 


c,{T) = c,(r) 

(B12) 

h(T) = h(r) + (T- r*)Cp(T’) 

(B13) 

s(T) = s(T-) + In 

(B14) 

f Tiqujq'p for T 

Tupper for T ]> T>iippQy 

(B15) 


B.9 kinetic_data 

The kinetic_data file defines possible chemical reactions and is optional. If 
the file is not found in the local run directory, it is assumed to be located in 
the [install-prefix] /share/physicsjnodules directory. See section A. 3 
for [install-prefix] . Reactants and products can be any species defined in 
the species_thermo_data described in section B. 8 . A sample entry looks like 
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1 


02 + M <=> 20 + M 

2.000e+21 -1.50 5.936e+04 

teffl = 2 

expl =0.7 4 

t_eff_min = 1000. s 

t_eff_max = 50000. e 

C = 5.0 7 

0 = 5.0 8 

N = 5.0 9 


H = 5.0 10 

Si = 5.0 11 

e- = 0 . 12 

The first line specifies the reaction while line 2 provides three coefficients of 
an Arrhenius- like equation, 

(B16) 


where c/ is the pre-exponential factor, rj is the power of temperature depen- 
dence on the pre-exponential factor, eo is the Arrhenius activation energy, and 
k is the Boltzmann constant. The arrowheads in line 1 signify the allowed 
directionality of the reaction. The symbol => denotes forward reaction only 
while <=> denotes forward and backward rates are computed. The coefficients 
in line 2 correspond to c/, rj, and e^/k, respectively. For reactions with a 
generic collision partner, M, such as this one, these coefficients correspond to 
Argon; and other collision partners and their efficiencies (multipliers of c/) 
are specihed on lines following line 5 and 6, which give the valid temperature 
range for the reaction. The effective temperature, T^ff, is dehned according 
to a given integer number in line 3. 

teffl = l,teff2 = 1 

This dehnes the formula to compute the effective temperature T^ff for 
the forward rate and backward rate, respectively. It is engaged for the 
case of thermal nonequilibrium. Options for teff are: 

'^eff = Ttr 

n. T'e^plT'l— expl 

-‘e// ~ -‘■tr 

3 : Teff = Ty 

where Ttr and T„ are translational and vibrational temperatures, respec- 
tively. 

expl = 0.7 

This is the exponent used to dehne the effective temperature when 
teffl= 2 (forward rate) or teff2 = 2 (backward rate). 
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rf_max = l.e+20 


This is the upper limit on forward reaction rate in cgs units when 
augment_kinetics_limiting = .true. For unlimited rates as function 
of temperature, see the output file kinetic_diagnostics_output. 

rf_min = l.e-30 

This is the lower limit on forward reaction rate in cgs units when 
augment_kinetics_limiting= .true. For unlimited rates as function of 
temperature, see the output file kinetic_diagnostics_output. 

rb_max = l.e+30 

This is the upper limit on backward reaction rate in cgs units when 
augment_kinetics_limiting = .true. For unlimited rates as function 
of temperature, see the output file kinetic_diagnostics_output. 

rbnnin = l.e-30 

This is the lower limit on backward reaction rate in cgs units when 
augment_kinetics_limiting = .true. For unlimited rates as function 
of temperature, see the output file kinetic_diagnostics_output. 

t_eff_min = 1000. 

This is the minimum temperature for T^jf. This may circumvent stiff 
source terms when computing reaction rates. 

t_effnnax = 50000. 

The maximum temperature for Tgjf. This may circumvent stiff source 
terms when computing reaction rates. 

B.IO species_transp_data 

The species_transp_data hie contains log-linear curve ht coefficients for 
species collision cross sections that are dehned based on temperature range 
of 2,000-4,000 K. [71] This temperature range spans boundary-layer temper- 
atures for typical hypersonic entry. The curve ht for the given coefficients is 
poor at temperatures below 1,000 K. Higher order curve ht data is available 
in species_transp_data_0. The hie should not be changed by the user unless 
there is a need to investigate other sources of collision cross-section data. If 
the hie is not found in the local run directory, it is assumed to be located in 
the [install-prefix] /share/physics_modules directory. See section A. 3 
for [install-prefix] . An example of the entries in the hie is 

Ar Ar i 

-14.6017 -14.6502 -14.5501 -14.6028 ! trrl32+kestin et al 2 

Ar+ Ar+ 3 
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4 


-11.48 -12.08 -11.50 -12.10 
Ar N2 

-14.5995 -14.6475 -14.5480 -14.5981 ! kestin et al 
Ar CO 

-14.5975 -14.6455 -14.5459 -14.5964 ! kestin et al 


B.ll species transp data 0 

The file species_transp_data_0 provides collision cross section coefficients 
[74,75] for a higher order curve £t data than those that are in the species_transp_data. 
The data in species_transp_data_0 supersedes the data in species_transp_data 
The file should not be changed by the user unless there is a need to investi- 
gate other sources of collision cross-section data. If the file is not found in 
the local run directory, it is assumed to be located in the [install-prefix] 
/share/physics jnodules directory. See section A. 3 for [install-prefix]. 

An example of the entries in the file is 


02 N 


111 (c 

-1.1453028E-03 
-1.0608832E-03 
1.4943783E-04 


1.2654140E-02 

1.1782595E-02 

-2.0389247E-03 


-2.2435218E-01 

-2.1246301E-01 

1.8536165E-02 


7.7201588E+01 

8.4561598E+01 

1.0476552E+00 


NO N 


111 (c) 

-1.5770918E-03 1 . 9578381E-02 

-1.4719259E-03 1 . 8446968E-02 

2.1014557E-04 -3 . 0420763E-03 


-2.7873624E-01 

-2.6460411E-01 

2.5736958E-02 


9.9547944E+01 

1.0911124E+02 

1.0359598E+00 


NO 0 


111 (c) 

-1.0885815E-03 
-1.0066279E-03 
1.4145458E-04 


1 . 1883688E-02 
1.1029264E-02 
-1.9249271E-03 


-2.1844909E-01 

-2.0671266E-01 

1.7785767E-02 


7.5512560E+01 

8.2644384E+01 

1.0482162E+00 


END END 
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0 . 0 . 0 . 0 . 

0 . 0 . 0 . 0 . 


B.12 hara_namelist_data 

The hara_namelist_data file controls the radiation models used by the Hara 
radiation module. [76,77] It is optional for coupled radiation simulations. If it is 
not present, then the code automatically chooses the radiative mechanisms as- 
sociated with species present in the flowheld that have number densities greater 
than 1000 particles/cm^) Other options are set to the defaults. For users not 
experienced in shock-layer radiation, the recommended default options should 
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be used, this hara_ncLmelist_data A default hara_namelist_data is available 
in the PHYSICS_MODULES directory of the Fun 3D distribution. 

specifying radiation mechanisms for atomic species: The treatment 

of radiation resulting from atomic lines, atomic bound-free, and free-free pho- 
toionization (referred to here as atomic continuum), and negative ion contin- 
uum is available for atomic carbon, hydrogen, oxygen, and nitrogen. These 
mechanisms are specihed through the following binary flags (on=l/off=0). If 
any of these flags are not present in hara_nconelist_data, then that flag is set 
to true only if the number density of the associated atomic species is greater 
than 1000 particles/cm^ somewhere in the flowheld. 

treat_[?] _lines 

A binary flag to enable the treatment of atomic lines for species [?] , 
where [?] can be c, h, n, and o, for atomic carbon, hydrogen, nitrogen 
and oxygen, respectively. 

treat, [?] _cont 

A binary flag to enable the treatment of atomic bound-free and free-free 
continuum for species [?] , where [?] can be c, h, n, and o, for atomic 
carbon, hydrogen, nitrogen and oxygen, respectively. 

treat, [?] _other 

A binary flag to enable the treatment of the negative-ion continuum for 
species [?] , where [?] can be c, h, n, and o, for atomic carbon, hydrogen, 
nitrogen and oxygen, respectively. 

specifying radiation mechanisms for molecnlar species: The treat- 

ment of radiation resulting from numerous molecular band systems is avail- 
able through the following flags (0 = off, 1 = SRB, 2 = LBL). The smeared 
rotational band (SRB) approach applies a simplihed and efficient treatment of 
each molecular band system, which is accurate for optically thin conditions. 
The line-by-line (LBL) approach is a detailed but highly inefficient treatment 
of each molecular band system. The LBL option is not recommended for cou- 
pled radiation-flowheld computations, except for possibly the CO 4+ system, 
which may be optically thick for Mars entry conditions. If any of these flags 
are not present in hara_namelist_data, then that flag is set to the SRB option 
only if the number density of the associated molecular specie is greater than 
1000 particles/cm^ somewhere in the flowheld. Additional band systems are 
listed in the following paragraph. These additional band systems are gener- 
ally considered negligible relative to those listed in this section. Therefore, for 
computational efficiency, they are not engaged by default. Dehnitions of each 
band system and the modeling data applied are discussed in Refs. [76,78]. 
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treat _band_c2_swan 

A flag activating the C2 Swan band system. 
treat _band_c2h 

A flag activating the C2H band system. 
treat_band_c3 

A flag activating the C3 and vacuum ultra-violet (VUV) band systems. 
treat _band_cn_red 

A flag activating the CN red band system. 
treat _band_cn_violet 

A flag activating the CN violet band system, 
treat _band_co4p 

A flag activating the CO 4 -\- band system. 
treat _band_co_bx 

A flag activating the CO B-X band system. 
treat _band_co_cx 

A flag activating the CO C-X band system. 
treat _band_co_ex 

A flag activating the CO E-X band system. 
treat _band_co_ir 

A flag activating the CO X-X band system, 
treat _bandJi2_lyman 

A flag activating the H2 Lyman band system. 
treat _band_h2_werner 

A flag activating the H2 Werner band system, 
treat _band_n2fp 

A flag activating the N2 H- band system, 
treat _bandji2sp 

A flag activating the N2 2 + band system, 
treat _bandji2pfn 

A flag activating the first- negative band system. 
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treat _band_n2_bhl 

A flag activating the N2 Birge-Hopfield I band system. 
treat _band_n2_bh2 

A flag activating the N2 Birge-Hopheld II band system. 
treat_band_no_beta 

A flag activating the NO beta band system. 
treat_band_no_delta 

A flag activating the NO delta band system, 
treat _bandjio_epsilon 

A flag activating the NO epsilon band system. 

additional molecular band systems: This paragraph lists molecular band 

systems available in addition to those listed in the paragraph above. The 
band systems listed here are generally weak emitters and absorbers, and are 
therefore not engaged as a default. Therefore, for these band systems to be 
engaged, the following flags (0 = off, 1 = SRB, 2 = LBL) must be present 
in the hara_namelist_data hie. The LBL treatment of these bands is not 
recommended. 

treat _band_c2_br 

A hag activating the C2 Ballik-Ramsay band system. 
treat _band_c2_da 

A hag activating the C2 Deslandres-d’Azambuja band system. 
treat _band_c2_fh 

A hag activating the C2 Fox-Herzberg band system. 
treat _band_c2_mulliken 

A hag activating the C2 Mulliken band system, 
treat _band_c2_phil ip 

A hag activating the C2 Philips band system, 
treat _band_co3p 

A hag activating the CO 3 + band system, 
treat _band_co_angstrom 

A hag activating the CO angstrom band system. 
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treat _band_co_asundi 

A flag activating the CO Asundi band system, 
treat _band_co_triplet 
A flag activating the CO triplet band system. 
treat _band_co2 

A flag activating the CO 2 band system. A value of two activates an 
approximate nonequilibrium model for UV emission, while a value of 
one assumes Boltzmann emission. The LBL treatment of this band is 
not available, 
treat _band_n2_cy 

A flag activating the N 2 Carrol- Yoshino band system, 
treat _band_n2_wj 

A flag activating the N 2 Worley-Jenkins band system, 
treat _band_n2_worley 

A flag activating the N 2 Worley band system, 
treat _bandjao_gamma 

A flag activating the NO gamma band system, 
treat _band_no_betap 

A flag activating the NO beta-prime band system, 
treat _band_no_gammap 

A flag activating the NO gamma-prime band system. 
treat _band_o2_sr 

A flag activating the O 2 Schumann-Runge band system, 
treat. [?] _photo_dis 

A binary flag activating the molecular photo-dissociation mechanism [79] 
for [?] specie, where [?] can be 02 or N2. This mechanism is not 
technically a molecular band system. 

treat. [?] .photo.ion 

A binary flag activating the molecular photo-ionization mechanism [79] 
for [?] specie, where [?] can be 02 or N2. This mechanism is not 
technically a molecular band system. 

treat jio.photo 

A binary flag activating the molecular photo-ionization mechanism [79] 
for NO. 
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atomic line models: There are various models available for atomic line radi- 

ation, one of which must be chosen for each specie that engages atomic line ra- 
diation (as specihed using treat. [?] .lines). This choice of atomic line model 
is made using the following flags. The listed defaults are applied if the indi- 
vidual flag is not present in hara.namelist.data, or if hara.namelist.data 
is not present in the working directory. All model types in this category must 
be surrounded by a quotation marks. 

c.atomic.linejiodel, h.atomic.linennodel 

A character identiher for selecting the atomic line model for atomic car- 
bon or hydrogen. Presently, the only available option is the model com- 
piled in Ref. [78], which is referred to here as the Complete Line Model 
(CLM). Default : 'dm' 

n.atomic.linennodel, o.atomic.line nnodel 

A character identiher for selecting the atomic line model for atomic ni- 
trogen or oxygen. The available models are compiled and compared in 
Ref. [76], which is referred to here as the Complete Line Model (CLM). 
Default : 'dm' Available models are: 

'all multiplets’ 

This model treats all lines as grouped multiplets. This signihcantly 
reduces the number of lines treated as well as the computational 
expense. However, this grouped multiplet approximation will lead 
to errors for non-optically-thin conditions. 

' dm' 

This model, which stands for Complete Line Model, applies the 
individual treatment of strong atomic lines while applying multiplet 
averages for weak lines. This is the recommended model. 

electronic state population models: These hags specify the model ap- 

plied for predicting the electronic state populations of atoms and molecules. 
The listed defaults are applied if the individual hag is not present in 
hara.namelist.data, or if hara.namelist.data is not present in the working 
directory. All model types in this category must be surrounded by a quotation 
marks, e.g. ‘ ’. 

atomic electronic states 

The electronic state populations for atoms are required for computing atomic 
line and photoionization emission and absorption. The compilation and com- 
parison of the available models are presented in Ref. [77]. 
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c_electronic_state, h_electronic_state 


A character identifier for selecting the electronic state model for atomic 
carbon and hydrogen. Available models are (default : ‘boltzmann’): 

' boltzmann' 

Applies Boltzmann population of electronic states. 

' Gally_lst_order_LTNE’ 

Applies the Gaily first-order local thermodynamic nonequilibrium 
method [80] , which approximately accounts for the non-Boltzmann 
population of atomic states. 

n_electronic_state, o_electronic_state 

A character identifier for selecting the electronic state model for atomic 
nitrogen and oxygen. Available models are (default : ‘CR’): 

' boltzmann' 

Same as for c_electronic_state 

' Gally_lst_order_LTNE' 

Same as for c_electronic_state 

'CR' 

Applies the detailed collisional radiative (CR) model developed in 
Ref. [77]. 

' AARC ' 

Applies the approximate atomic collisional radiative (AARC) model 
developed in Ref. [77]. This model is essentially a curve-fit based 
approximation of the CR model, which allows for improved compu- 
tational efficiency with a slight loss in accuracy. 

molecular electronic states 

The electronic state populations for molecules are required for computing 
molecular band emission and absorption. The compilation and comparison 
of the available models are presented in Refs. [77,81]. 

molecular_electronic_state 

A character identifier for selecting molecular electronic state for all molec- 
ular band systems. Available models are (default : ‘CR’); 

' boltzmann' 

Applies Boltzmann population of electronic states. 
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'CR' 

Applies a detailed collisional radiative model considering both heavy- 
particle and electron impact transitions. Some molecular states 
are still assumed Boltzmann with this model because no data is 
presently available for the CR model. 

other flags: 

use.triangles 

A logical flag specifying whether optically-thin atomic lines are modeled 
as triangles to reduce computational time. This option has shown to 
result in a negligible loss of accuracy while greatly reducing the compu- 
tational time, [76] and is therefore recommended. Default ; .true. Note: 
This flag is automatically set to .true, when n_ or o_atomic_line jnodel= 

' dm’ — see atomic line models earlier in this section. 

use_edge_shift 

A logical flag to engage the photoionization edge shift [76] for atomic 
bound-free radiation. (on=l/off=0). Default ; .true. 
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Appendix C 


Troubleshooting 


The goal of the Fun 3D developers is to produce as robust a solver as 
possible. However, there are times when the code fails to produce a converged 
solution. For example, taking the square root of a negative quantity (due to a 
negative density or pressure) results in a NaN. We hope that these suggestions 
are helpful. If none of the suggestions listed here remedy your problem, please 
contact Fun3D-Support@lists.nasa.gov. 

C.l What if the solver has trouble starting or reports 
NaNs? 

Check that the freestream, reference, and boundary conditions are specihed 
correctly. Visualize the solution, especially near the location of the maximum 
residual. If the problem is widespread, run the simulation again and visualize 
the solution a few iterations before the problem happens. Look for extremely 
large Mach numbers, low pressures, low densities, or reversed flow at bound- 
aries. 

Examining the residual history may help to isolate the problem to the 
mean flow or turbulence model. Lowering the CFL numbers of the mean- 
flow and turbulence equations can aid linear and nonlinear convergence, see 
section B.4.14. If the linear system is diverging (the linear system can be 
examined with the --monitor_linear command line option), utilize a more 
dissipative flux linearization f lux_construction_lhs or the Krylov projection 
method linear _projection=. true., see section B.4.15. 

Try flow held initialization in the problematic region of the domain (e.g., 
engine plenum), see section B.4.19. Start with some f irst_order_iterations 
(section B.4.9) or try continuation from less challenging freestream condition 
(e.g., lower angle of attack, subsonic Mach number). The time accurate how 
solver may be able to survive initial transients better than the steady solver. 

C.2 What if the forces and moments aren’t steady or 
residuals don’t converge to steady-state? 

Try lowering the CFL numbers of the mean how and turbulence model, see 
section B.4.14. Examining the residual history may help to isolate the problem 
to the mean how or turbulence model. The problem may be unsteady; try 
restarting the solution with a time-accurate simulation. 
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C.3 What if the solver dies unexpectedly? 

You may need to set your shell limits to unlimited, 

$ ulimit unlimited # for bash 
$ unlimit # for c shell 

If your operating system reports a Signal 9 or 11 and you have already tried 
removing shell restrictions, you have likely hit the memory limit of your ma- 
chine. Try reducing the number of mesh points, running on more nodes, or 
installing more memory on your machine. 

C.4 What if a segmentation fault occurs after “Calling 
ParMetis”? 

Make sure that the the width (32 or 64 bits) of integers in Fun 3D and 
ParMETIS are consistent. More recent implementations of MPI (e.g., Open- 
MPI) internally manage the handles (i.e., communicators) differently from 
previous versions of MPI. However, ParMETIS 3.* uses an older paradigm, 
which has been updated in ParMETIS 4.*. Upgrade to ParMETIS 4.*. 

C.5 What if the solver dies with an error like “input 
statement requires too much data” after echoing 
the wrong number of elements or nodes? 

The endianness (section 4.1) of the grid hies (section 4) may be different than 
Fun 3D expects. 

C.6 What if the solver dies with an error like “input 
statement requires too much data” after echoing 
the number of tetrahedra and nodes for a VGRID 
mesh? 

Single-segmented VGRID grids over 20 million nodes exceed the allowable 
record length. Use postgrid to save grid as a multi-segmented format (option 
05 in batch mode). 

C.7 What if the solver reports that the Euler numbers 
differ? 

The Euler number is a global indicator of consistent node, element, and face 
connectivity. There is some limited evidence that suggests there may be times 
when it reports a problem that may not be an issue for the solver, but the 
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failure of the Euler number check indicates a problem with the grid in a ma- 
jority of cases. Instructions to determine if the Euler number will impact your 
solution follow this description of the Euler number. 

C.7.1 Euler Number Description 

A valid grid is composed of four elemental volume types (tetrahedra, pyra- 
mids, prisms, and hexahedra) face-connected either to each other or one of 
two boundary face types (triangles or quadrilaterals). Each boundary edge 
connects to precisely two boundary faces. Two neighboring boundary faces 
share exactly one boundary edge. For each boundary face connecting to a 
boundary node, every other boundary face connecting to the same boundary 
node can be found by a path through a connected-edge/connected-face traverse 
starting from that boundary face. 

The above restrictions are meant to exclude certain topologies such as two 
spherical boundaries coming together at a point or two rectangular boundaries 
connecting along an edge. These restrictions are not checked explicitly but will 
cause the Euler number check described below to fail. 

The Euler Number computed from boundary data {ENf,) is 

ENh = Nh-Eh + Et (Cl) 

where 

Nf, = boundary nodes (counted) (C2) 

Eij = boundary edges (inferred fromiVt^i and Nq^ad) (C3) 

Ffe = boundary faces (inferred from Ntn and Nq^ad) (C4) 

The Euler number is a characteristic number for the topology of the boundary 
or boundaries. Nt^i and Nq^ad are the number of triangular and boundary 
faces, respectively. 

The Euler Number computed from volume data {EN^) is 


EN^ = 2{N-E + E-C) (C5) 

where 

N = volume nodes (counted) (C6) 

E = volume edges (counted) (C7) 

E = volume faces (inferred from C and Ef,) (C8) 

C = volume cells (counted) (C9) 

The formula that is checked is 

EN^ - ENb = 0 (CIO) 
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Barth [82] derived this formula for tetrahedra and noted the formula does 
not hold in certain cases, such as two simplices that share only one common 
edge or two simplices that share only one common node. Barth notes that the 
above formulas are specihc forms of the general Dehn-Sommerville formula, 
reported in Wikipedia to hold for simplicial polytopes and simple polytopes. 
The pyramid is not a simple polytope. It can be proved by induction [83] that 
the formula holds for every valid grid as dehned above. 

Try this checklist to diagnose the problem: 

1. Check the ENi, with your expectations for this case: 

2 for a spherical topology, simple 3D wing with symmetry, . . . 

0 for a torus, donut, . . . 

-2 for a double torus, . . . 

-4 for a triple torus, pretzel, . . . 

4 for a sphere within a sphere, . . . 

6 for two spheres within a sphere, . . . 

2. Ensure the number of boundary nodes W and faces T], reported match 
expected values. 

3. Ensure the number of nodes N and cells C reported match expected 
values. 

4. The difference between EW and points to inconsistencies in edge 
counts, i.e., 5{E) = 2{ENh — EN^) ^ 0. The inequality EW > ENy 
implies you have more edges than expected. When this occurs, the re- 
ported face counts will differ from an actual count. An error of this type 
would arise when there are adjacent faces that are inconsistent, such as 
a quadrilateral face shared between two elements that is cut into two 
triangular faces by different edges. 

C.7.2 Determining the Impact of an Euler Number Mismatch 

A freestream residual problem localization technique is described. However, 
the best practice is to not proceed without repairing the grid to ensure EN\j = 
The ignore_euler_number namelist variable does just what the name 
implies, and allows the solver to proceed. The --test_freestream option can 
be used as a secondary check on the mesh. On a valid mesh, the solver should 
preserve the freestream for an arbitrary number of iterations. You should run 
20-50 iterations, which may require a lowering of the stopping_tolerance 
to le-20 so the solver does not automatically stop. All residuals should 
hover around machine zero, and not slowly increase (there will be iteration- 
to-iteration variation in the exact number, however). 
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If freestream is maintained by this test, you could proceed with your in- 
tended computation using only ignore_euler_number, but this is not recom- 
mended. If freestream is not maintained, this test confirms that there is a 
problem with the mesh and the location of the max residual may give a clue 
as to where in the mesh to start looking for the problem. 
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